Client/Server Overview

Provides the Symbian OS client/server framework, by which a program can offer services to multiple other programs. Servers also handle resources on behalf of multiple clients.

All Symbian OS developers should have a general understanding of this API in order to understand the design of many Symbian OS system APIs. In specialised circumstances, developers may also create their own server programs.

Many important Symbian OS system APIs use the client/server framework to provide services to client programs: for example, the Windows Server, File Server, and Messaging. In some cases, such APIs provide extensive client-side classes that hide the direct use of the client/server interface from the client program.

The API has four key concepts: server (CServer2), session (CSession2 and RSessionBase), sub-session (RSubSessionBase), and message (RMessage2, and RMessagePtr2).

A server program offers services to other processes through a client interface API that it defines. Clients and servers use a message passing protocol to communicate.

Client/server is usually chosen, rather than a conventional shared library, to provide services when one or more of the following is required:

• management of shared system resource

• asynchronous services

• the protection offered by running in a separate process from clients.

A client/server implementation supplies a server program executable, and a .DLL containing the client-side interface.

The server is the central class of any server program. It is responsible for handling requests by clients to establish a connection to the server.

The base server interface is provided by CServer2.

The session is the channel of communication between a client and a server.

The base client-side session interface is provided by RSessionBase. An implementation derives from this to define the functions that it wants to expose to clients.

The corresponding server-side session base classes is CSession2. A session can be shared between different client threads if the server marks the session as sharable. An implementation defines in a derived class how client messages should be handled.

The sub-session presents an efficient refinement of a session where a client wants multiple simultaneous uses of a server. For example, with the File Server, each opened file is handled through a separate sub-session.

The base client-side sub-session interface is provided by RSubSessionBase. An implementation derives from this to define the functions that it wants to expose to clients.

A server implements a corresponding sub-session class based on CObject, CObjectCon and CObjectIx, the Reference Counting Objects API.

The message is the information passed between client and server. It consists of a code that identifies the type of request that the client is making, and up to four 32-bit data arguments together with information about each argument's type, width and accessibility. It is also possible to pass just the code, with no arguments.

Clients do not use messages directly; they use a TIpcArgs object to package the message information that is to be sent to the server.

Server-side sessions and subsessions access this information through an RMessage2 object.

Package Buffers Overview

Reference Counting Objects Overview

Threads And Processes Overview