The client-server approach is one of the most common techniques of communicating between applications over a network. In this approach, a client application sends a request to a (possibly remote) server application, which performs that requests and returns a matching result/reply. Consider, for example, accessing your bank account through a web browser. Your browser is the client application, communicating with a remote web server sitting at the bank computer. Your operations on your bank account interface are translated into requests sent from your browser to the server. The server processes your requests and replies with results in the form of visual data (web pages) that are displayed to you by your browser.
An ongoing effort to standardize the concept of client-server interaction, taking place in the academia and the industry, has resulted in the construction of middlewares: these are specialized layers of software dedicated to hiding all the inter-application (and inter-machine) communication protocols under a simple method call from a client application to a server interface, which can be located anywhere in the network. A few examples of such middleware standards are: CORBA (OMG), J2EE (Sun Microsystems), .NET (Microsoft), Web Services (W3C). Most of these standards aim to create distributed applications as collections of distributed object that communicate regardles of the operating environment (OS/language/..) in which each object was deployed.
One inherent drawback of the client-server technique is that a client depends on the server to continue functioning. As more clients depend on the same server, the server downtime becomes more costly. To reduce this effect, several approaches were taken, all of which can be regarded as different kinds of backup techniques:
Basically, a group communication (GC) toolkit is a software layer that makes guarantees for the transfer of messages between members of a process group. The processes (applications) in the process group send messages using the toolkit, either point to point or to the entire group (multicast). These processes also share a common knowledge of the view - the list of all the group members that are still functioning. This view is updated whenever at least one of the members is suspected to be faulty, is leaving or is joining the group. Whenever that happens, the "non-faulty" group members need to agree upon and install a new view of the group. One of the most fundamental attributes of GC is the reliability of communication - a message that is sent by a process during one view is bound to be received by all the processes that install the next view with the sender. GC further features total ordering of messages - all messages arrive in the same order at all the recipients. This property is essential for data updates, since updates have to be applied in the same order in all the replicas of the data in the participating servers so that the replicas remain consistent.