Replication, literally, means the synchronizing of the same piece of data into multiple locations. Usually applied to having two copies of a database on two different machines (often servers), and ensuring that a change to one DB causes the exact same change to be made to the other DB.
The main uses are:
- live backups
- online/offline, e.g. a laptop takes a copy of the DB whilst online, goes offline, then days / weeks later goes online again and replicates any changes that have been made to the laptop’s copy (and/or to the server’s copy)
Replication takes considerable time, and is usually not done as part of a live system because it would slow things down far too much. NB it’s usually done as a background process, e.g. triggering every 5 minutes, or every day, etc.
[quote]I want to distribute software/functions, not divide the world. For example, the chat program should allow several servers to share one chat room, instead of one chat room per server. That is my idea of replication (unless my research is bad).
My research into RMI indicates that that API supports only distribution, not replication.
[/quote]
If our previous posts seem to have been off-topic for your problem, you’ll need to describe it better (and perhaps make it clear how / why you think you want to replicate?). Basically, it’s not clear what problem you think you are solving, nor how you think you are doing it.
True replication (as described above) is indeed not supported by RMI, but it’s also not supported by anything except databases. Yes, you could replicate your MUD db to multiple servers, but not in real time. And that wouldn’t help chat rooms, unless you have DB-backed chatrooms. Or you might be wanting to do multi-source multicast (a chat-specific feature), but I thought you wnated something more general than just for your chatroom? I’m not sure…
I suggest you explain your chat room example in more detail, since it’s not clear what you want to happen…?