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.