Features of the client-server architecture

Each session maintains its own context. This allows sessions to be owned by different active objects within the same thread, by different components within the same thread, etc., without interference.

Client-server communication requires context switching:

• messages are sent via the Kernel

• handling the message involves a switch from client thread, to server thread, and back to client thread

• inter-thread data transfer can never be done with simple C++ pointers: it always involves data copying. Furthermore, it may involve cross-address-space data transfer, if the threads are in different processes.

Compared with a simple function call or memory copy, context switching is a relatively expensive operation, and should be minimised. Servers whose performance is critical use buffering to minimise context switches. Sometimes, this is transparent. Often, the client interface design is affected by the requirement for buffering.

The basic architecture of servers is thread-based. This gives the implementers of a system the flexibility to package the server threads into whatever processes they choose, depending on the balance of requirements for security and economy.

This can be contrasted with other systems in which all, or most, servers run as part of the Kernel. On Symbian OS this is not necessary, so security is better.

Client-server policies can be contrasted with systems which require servers to have their own process. This uses more memory (e.g. for address translation tables), and has worse performance (inter-thread data transfer involves translation as well as copying).

When a client process terminates, all server resources associated with it should be cleaned up.

When a session is ended, servers must clean up all objects associated with it, and clients must consider any handles associated with it as invalid, and perform any necessary client-side cleanup.

For a non-sharable session, if the client thread dies, then the Kernel performs thread-death cleanup and sends a disconnect message to the server end of all sessions associated with that client thread.

For a sharable session, the death of any or all client threads does not trigger closure of the session. This is because the session is process relative. To close a shared session, either the process must terminate, or the session must be explicitly closed through a client side call to Close() on the client-side session handle, RSessionBase.