Replication Documentation

[Ken Carpenter]

The following is the only documentation I can find on Ice replication:

Section 4.3.2, page 56 of Ice documentation:
Ice also provides support for replicated servers. Replication permits multiple servers to each implement the same set of object instances. This improves performance and scalability (because client load can be shared over a number of servers) as well as redundancy (because each object is implemented in more than one server).

Is there any other documentation, even in an early form?

I need to make a decision sometime next week on whether to use Ice for our massively multiplayer game project, so I really need to wrap my head around what Ice can and can't do. I don't need to know all the details of replication, but a good overview would be extremely helpful.

Thank you,


Ken Carpenter

[marc]

I'm afraid no, we don't have documentation for replication yet.

Here is how it works in a nutshell: You start several replicated servers, and give the client proxies that contain endpoints to all these servers. The client will pick one of the servers randomly (load-balancing), and will automatically switch to another server if one crashes (fault tolerance).

Note that the only role of Ice in this is the ability for clients to choose and change servers. How server are replicated is an application specific task.

In my experience, the difficulty of server replication can range from anything between easy and "fantasy material". For example, it's obviously easy to have replicated state-less servers (or servers that only read their state once upon startup).

A good example for such state-less servers in your domain (online gaming) is a server-side pathfinder: When a pathfinder server starts up, it loads mesh data from disk, preprocesses it, and is then ready to receive requests. Requests from clients do not alter the server state, therefore it's trivial to have several pathfinders on different hosts, for fail-over and load-balancing.

Servers with slowly changing state are also doable, but require more work. You must make sure that the state between the servers is always replicated.

Finally, having general replicated high-performance servers with fast-changing but still permanently synchronized state are IMO fantasy material. I've seen too many attempts from my CORBA days, and none of them was ever usable in a real-world environment.

[felixcollins]

That's interesting information. Will there be any support of non-homogeneous servers? (eg some objects on one server and the rest on another - clients get transparently directed to which ever one is needed) This would make support for stateful objects easier with load balancing replication.

If the objects can have references to each other, a way of optimally partitioning the objects to minimise the references between the servers would be useful.

Cheers,
Felix

[nsns]

The topic of the server replication is very important for many applications.
In my project (the Grid Computing) I would like to use this feature.
What I need is

the ability for clients to choose and change servers.

In my project the server is an home-made database which can be replicated.
I have two kinds of clients: one with read-only access (and it is for them I need this Ice feature),
the second with write-only access. The properties of updates are such that I chose
the primary-based replication, i.e. I'll have one master DB and many slave DBs.
A small desynchronization is acceptable.
I'm going to use the IceStorm service for the update propagation.

Cheers, Nikolai