Sessions -and requests

diff -r 51a74ef9ed63 -r ae94777fff8f Symbian3/SDK/Source/GUID-9169062F-3B6D-544C-847C-BA859DAB33B9.dita --- a/Symbian3/SDK/Source/GUID-9169062F-3B6D-544C-847C-BA859DAB33B9.dita Wed Mar 31 11:11:55 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9169062F-3B6D-544C-847C-BA859DAB33B9.dita Fri Jun 11 12:39:03 2010 +0100 @@ -1,92 +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.