Sessions +and requests

diff -r 000000000000 -r 89d6a7a84779 Symbian3/SDK/Source/GUID-9169062F-3B6D-544C-847C-BA859DAB33B9.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-9169062F-3B6D-544C-847C-BA859DAB33B9.dita Thu Jan 21 18:18:20 2010 +0000 @@ -0,0 +1,92 @@ + + + + + +Sessions +and requestsDescribes communication between the client and the server in the +client-server framework. +

Communication between client and server is represented by a session; +this is initiated by the client. A client thread may have several sessions +with a server. A session can also be shared by all the client threads in a +process, if supported by the server, and also by all threads across all processes, +again if supported by the server.

Sessions are maintained by the Kernel and the important points are:

The client has an RSessionBase handle +to the session.
The server uses a CSession2 -derived +class to represent the session.
A session may be sharable +between the threads in the client process, between all threads across all +processes, or it can be restricted to the thread connecting to the server.

If a call to the client interface requires a service from the server, the +client interface must set up and send a message. The message has a 32-bit +operation code to identify the request, and up to four 32-bit parameters. +The message is encapsulated within a TIpcArgs object. The +process can be summarised as follows:

The client sends the +message to the server using RSessionBase::SendReceive(). +This call eventually returns with the completion code.
The Kernel packages +the operation code and parameters and delivers an RMessage2 to +the server.
The server delivers +the message to the appropriate CSession2 object, which deals +with the request. The request is handled by CSession2::ServiceL(). +This is defined as pure virtual in CSession2, and is implemented +by the class derived from CSession2. When the session has +finished dealing with the request, it calls RMessage2::Complete() to +indicate that the service has been performed and to return a 32-bit result +to the client - this is returned from the SendReceive().

The client-server framework also supports the sending of requests asynchronously +to the server.

The following diagram illustrates this:

+ + +

Sending messages asynchronously to the server

+ +

A server can support multiple connections from a client in a number of +distinct ways:

The client may have +a number of concurrent sessions with a particular server.
Each session is independent +of any other within the client thread; Connect() must be +called to initialise each new connection.
The client may create +a number of subsessions within a single session.
Each client subsession corresponds +to a subsession object in the server. The client subsession contains +a handle to this subsession object. All communication is via the owning session; +the handle is used to match up corresponding client subsessions and subsession +objects.
Subsessions use fewer +Kernel resources than sessions, although they are slightly more complex to +use.

A server can support the creation of sharable sessions allowing either +all the threads in a client process to share a single session, or allowing +all threads across all processes to share a single session. The important +points are:

The server must support +the sharing of sessions.
The connecting thread +can make the session sharable after creation, or it can create the session +as sharable.
Up to 255 threads can +be concurrently attached to a session.