3.2 Communication Architecture

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.

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:

1.

Thin Server:
The server was kept as small as possible. The clients themselves perform time-consuming operations. This reduces the workload of the server and permits a higher number of participating clients. To keep the server simple also improves the stability of the server. This is a very important factor, since a malfunction of the server is more critical than then a failure of the client.

2.

Usage of replicated objects:
Distributed objects are accessed by a number of remote clients. There are different methods to organize the distribution of objects. One way is to generate a set of replicated copies that stay at the clients side. Every time a client changes a distributed object it has to be sent to the server which forwards those changes to other clients that share the same distributed object. Another possible method is to distribute objects in the form of non-replicated remote objects. Only a single copy, which remains at the server, exists in this case. A network transaction is made every time a client needs to access the object. Of course, this implies a big network overhead. This is especially the case if an object is accessed frequently. Another disadvantage is that the remote object is lost as soon as the server or the connection to the server fails.

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 4.2.1.3 deals with a method that has been used to prevent inconsistent states of distributed objects amongst clients.