Features +of the client-server architecture

Context

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.

Context switching

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.

Thread-based

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 platform 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).

Cleanup

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.