Hemelix

Client Server Framework

Servers handle access to system resources on behalf of multiple clients (applications which use the services of server) (e.g. file server, window server are server provided by Symbian OS) Servers can be loaded as :
-an independent process in memory(Can be loaded by OS, other application etc)
-in their own thread created by other process
Servers are accessed from applications and other threads by a server client API.
The client-server framework is used to access system resources such as opening files, making telephone calls, setting the alarm, etc. These resources need to be carefully controlled so that concurrent access from different threads will not cause any problems. It is the Server that handles the access to the resource and the Client that requests access.
Servers run within their own process or thread and any requests from clients are done across thread boundaries. This means that the server has the ultimate control over the resource and can fail any requests that would cause an error, for example a file delete request from one application, when another application was editing the file.
Another example can be mentioned as telephony server. When we make a phone call, then some other person may call us. This multiple useage must he handled carefully so system does not crash.
Why server is used in Symbian OS:
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.

Following figure shows how client1, client2 communicate with client side of the server. Normally client can be an application or it can be another server. Client side is a DLL that knows how to pass message from client to server. Client side of the server is normally a DLL, client can linked to the DLL statically.

A client/server implementation supplies a server program executable, and a .DLL containing the client-side interface.
Following are the most important concept when we discuss about client server in Symbian OS.

Server
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.
Session
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.
Sub-session
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.
Message
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.

coming more soon

Download area

Download source code (HelloMyCountServer.zip)

Download Asyncronuos and subsession (AllclientServer.zip)

Download presentation material(clientserver_basic.ppt)