19.3. Client-server system architecture

It is clear that, in general, an application program running on a workstation can request a service from some server, at least some interface program layer is required that supports this kind of interaction (it would be at least unnatural to require the application program to directly use primitives). transport network level). From this, in fact, follow the basic principles of the client-server system architecture.

The system is divided into two parts that can be performed in different nodes of the network, the client and server parts. The application program or the end user interacts with the client part of the system, which in the simplest case provides just the above network interface. The client side of the system, when needed, accesses the server side over the network. Note that in developed systems, network access to the server part may not be necessary if the system can anticipate the user's needs, and the client part contains data that can satisfy his next request.

The server side interface is defined and fixed. Therefore, it is possible to create new client parts of the existing system (an example of interoperability at the system level).

The main problem of systems based on the client-server architecture is that, in accordance with the open systems concept, they are required to mobility in the widest possible class of open-source hardware and software solutions. Even if we confine ourselves to UNIX-oriented local networks, different networks and communication protocols are used in different networks. Attempts to create systems that support all possible protocols, leads to their overload network details at the expense of functionality.

An even more complex aspect of this problem is related to the possibility of using different data representations in different nodes of a heterogeneous local network. Different computers may have different addressing, numeric representation, character encoding, etc. This is especially important for high-level servers: telecommunications, computing, databases.

A common solution to the problem of mobility of systems based on the client-server architecture is to rely on software packages that implement Remote Procedure Call (RPC) protocols. When using such tools, accessing the service in a remote site looks like a normal procedure call. Means RPC, which, of course, contains all the information about the specifics of the local network equipment and network protocols, translates the call into a sequence of network interactions. Thus, the specifics of the network environment and protocols is hidden from the application programmer.

When you call the remote procedure, the RPC programs convert the client data formats to intermediate machine-independent formats and then convert them to server data formats. When transferring the response parameters, similar transformations are performed.

If the system is implemented on the basis of the standard RPC package, it can be easily transferred to any open environment.