Introduction to the client-server architecture

Why use a server?

It is usually appropriate to provide services through a server:

• when the services involve management of one or more shared system resources.

  For example, the File Server manages all files and file systems on behalf of all client programs. The file server may therefore ensure that all file resources are correctly shared. Similarly, the Window Server allows all applications to share the machine's screen, keyboard, and pointer devices.

• when a degree of isolation is required between client and server.

  Since client and server run in separate threads, they may also run in separate processes, with separate address spaces. This means there is no possibility of communication between them except by the interface provided by the server and its client interface. Thus, misbehaved clients cannot corrupt the server or any of the resources it manages on behalf of other clients.

  The File Server architecture is strongly motivated by this requirement.

• when asynchronous services are required.

  Asynchronous requests can be handled using Kernel services (e.g. timers) and active objects within an application thread. However, when the completion of a request is some time in the future, and the application program making the request might no longer be present, a continuously-running server is appropriate.

Most servers are motivated by a combination of requirements such as these.

There are three distinct aspects to the service provided by a server:

• a server program, which runs in its own thread

• several client programs, each running in their own thread

• a client interface, provided by the server, for use by each client program

Symbian platform client/server

In Symbian platform, the server defines a client interface API which the client uses to request specific services. The client and server programs run in different threads, often in different processes, and so cannot directly access each other's address space. They use a message passing protocol to communicate.

All servers have a name which is passed to the server when it is started. A client finds a server through its name.

The channel of communication between a client and a server is known as a session. To make a server request, the client sends a message to the server over the session. The message includes a 32-bit request type code, and up to four 32-bit parameters. The server may use data transfer services to send and receive additional data. When it has finished servicing the message, a 32-bit completion code is returned to the client. All client-server communication is mediated by the Kernel.

A session can be used by all threads in a process, and an also be shared by all threads across all processes, and not just by the thread that connected to the server. Such a session is said to be sharable.

A server must indicate that it can support sharable sessions. Default behaviour is always to create non-sharable sessions.

The Symbian platform provides several servers.