Client/Server Structure

At the broadest level, Relay is a client/server system. A client/server system provides us with a well-known location for group management and initial connection. Scalability can be achieved with a hierarchy of servers. The hierarchy can grow as the number of clients grows to keep the clients/server ratio to an efficient level. A parent server can be designated when the server is started. Parent and child servers treat each other as if they were client applications: a child propagates any update it receives to its parent, and vice versa. We must be careful to avoid sending updates in cycles between a server and its parent.

We chose to use a server hierarchy to avoid peer-to-peer group management, but both structures have desirable properties. While client/server with a server hierarchy simplifies design, it becomes crippled when the system of servers is partitioned. Peer-to-peer structures with randomized anti-entropy exchanges are more robust on unreliable networks, but require group management. A combination of client/server and peer-to-peer might exploit the advantages of both structures. Clients could connect to well-known servers while the servers achieve scalability through a peer-to-peer topology using TSAE to propagate updates. The server topology is independent of how client applications operate. Client applications connect to a server, but they are unaware of how their updates are propagated throughout the system.

We make the following simplifying assumptions with respect to how the Relay server and client-side caches work:

• Caches operate outside the kernel in the application address space for portability to the diverse systems in the Internet. The drawback to a user-level cache is that the cache requires the application programmer to notify it of object updates. The cache cannot detect data accesses on its own. The cache must present an API to the application developer for access to cached data.
• Caches are replicas - Caches contain a copy of every object in the shared state.
• Caches need the ability to decide which updates get applied to enforce eventual consistency based on timestamps assigned by servers. Applying an update supersedes all earlier updates for an object because the update encapsulates the entire state of the object.
• Constant connections are required for operation. This simple implementation does not support disconnected operation or unreliable connections. Relay could accommodate disconnected operation through the use of queuing strategies [8]. Updates could be placed in a queue when there is no connection. When a connection is made, the client and server exchange the latest pending updates.
• Shared state is not recoverable. This implementation of a shared data space will not deal with crash recovery.