An important preparatory task was to design a communication architecture that allows all participants to access the artifacts in a synchronous way. Applications for synchronous communication usually use a form of client/server architecture.
A server process is the central piece of a client/server system. Clients connect to the server in order to obtain a service provided by the server. In our system, a server can be used to receive messages from clients, which are forwarded to a one or a group of other clients. The greatest advantage of this architecture is its simplicity. In addition, the server can be used to prevent problems caused by the simultaneity of distributed systems. The synchronous nature of distributed objects can lead to inconsistent states among the client. The server can in this case be used to serialize processes in order to prevent inconsistencies.
A disadvantage of the client/server architecture is its centralized nature. The server is the bottleneck of the system. The system can become slow or even unusable if the capacity of the server is not sufficient to reply to client requests in a reasonable time. This is caused either by the network leading to the server whose bandwidth is exhausted or by the server machine itself, which is too slow to answer multiple client requests. In addition, the whole system is only functioning if the server is working. A server crash would mean a complete break down of the whole system.
Although the number of participants is unlimited, it is unlikely that there are much more than ten users present in a session at a time. A session might become confusing if too many users act at the same time. This limits the risk of overloading the server. However, many sessions may run simultaneously which again increases the server workload. An alternative to the client/server architecture would be a decentralized system, where all clients operate as loosely coupled peers. A real decentralized system is however complex and hard to implement. It was therefore decided to use the client/server architecture after all. Precautions have been made to limit the disadvantages of a client/server system:
It was therefore decided to use replicated objects. The current state of the session is replicated for every client at all times. A complete failure of the server would not cause the loss of a session since the clients have a copy of the session. It can be saved and restarted once the server is working again. The replicated scheme has although the disadvantage of a bigger development overhead, because replicated objects again introduce problems regarding concurrent events. For example, an inconsistent state would arise if two users send a changed object to the server at almost the same time. Section 18.104.22.168 deals with a method that has been used to prevent inconsistent states of distributed objects amongst clients.