Sessions and requests
Describes 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:
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: