<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-9169062F-3B6D-544C-847C-BA859DAB33B9" xml:lang="en"><title>Sessions

and requests</title><shortdesc>Describes communication between the client and the server in the

client-server framework.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>Communication between client and server is represented by a <i>session</i>;

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. </p>

<p>Sessions are maintained by the Kernel and the important points are: </p>

<ul>

<li id="GUID-C8D3B5F7-6BCE-5AB2-A11D-F0436F8CE20C"><p>The client has an <codeph>RSessionBase</codeph> handle

to the session. </p> </li>

<li id="GUID-80F84FC0-AA11-5C5E-A067-A23D6069DE00"><p>The server uses a <codeph>CSession2</codeph> -derived

class to represent the session. </p> </li>

<li id="GUID-B6405FDE-1ECB-543E-BA11-6280A5CD8DF8"><p>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. </p> </li>

</ul>

<p>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 <xref href="GUID-4AD02F14-1142-372F-9D11-224595932034.dita"><apiname>TIpcArgs</apiname></xref> object. The

process can be summarised as follows: </p>

<ul>

<li id="GUID-2810FEA1-D51E-534E-963C-425D9A3B09C0"><p>The client sends the

message to the server using <codeph>RSessionBase::SendReceive()</codeph>.

This call eventually returns with the completion code. </p> </li>

<li id="GUID-785468D3-7D69-5A2C-818D-5961DCCB7FCA"><p>The Kernel packages

the operation code and parameters and delivers an <codeph>RMessage2</codeph> to

the server. </p> </li>

<li id="GUID-7BF7D799-7999-51C8-BEBF-88822703F113"><p>The server delivers

the message to the appropriate <codeph>CSession2</codeph> object, which deals

with the request. The request is handled by <xref href="GUID-D5A30C75-E22C-34E8-913B-7D2CA6AD5C51.dita#GUID-D5A30C75-E22C-34E8-913B-7D2CA6AD5C51/GUID-B37413F7-D8FD-35AD-A037-99023D7CE986"><apiname>CSession2::ServiceL()</apiname></xref>.

This is defined as pure virtual in <codeph>CSession2</codeph>, and is implemented

by the class derived from <codeph>CSession2</codeph>. When the session has

finished dealing with the request, it calls <codeph>RMessage2::Complete()</codeph> to

indicate that the service has been performed and to return a 32-bit result

to the client - this is returned from the <codeph>SendReceive()</codeph>. </p> </li>

</ul>

<p>The client-server framework also supports the sending of requests asynchronously

to the server. </p>

<p>The following diagram illustrates this: </p>

<fig id="GUID-97810C53-3BF6-5ECF-B413-86EEE99E68DA">

<image href="GUID-08E31D57-A84D-5B6B-B16F-3F7025A763E9_d0e240610_href.png" placement="inline"/>

<p>Sending messages asynchronously to the server</p>

</fig>

<p>A server can support multiple connections from a client in a number of

distinct ways: </p>

<ul>

<li id="GUID-DFBDEB83-48DE-5A94-A07B-B9BA1715FDE7"><p>The client may have

a number of concurrent sessions with a particular server. </p> </li>

<li id="GUID-C382BBE4-A94B-593E-9C9E-1E2E4DA60587"><p>Each session is independent

of any other within the client thread; <codeph>Connect()</codeph> must be

called to initialise each new connection. </p> </li>

<li id="GUID-343295A2-AAE6-51AA-AFCF-5CD3CD39A510"><p>The client may create

a number of <i>subsessions</i> within a single session. </p> </li>

<li id="GUID-7228AA13-B73F-5996-8535-0C959B7C7788"><p>Each <i>client subsession </i> corresponds

to a <i>subsession object</i> 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. </p> </li>

<li id="GUID-8D01708B-CCC3-5B6C-9C26-4A4BE26A3D0C"><p>Subsessions use fewer

Kernel resources than sessions, although they are slightly more complex to

use. </p> </li>

</ul>

<p>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: </p>

<ul>

<li id="GUID-81929E38-1251-51C9-A3B0-CD82AD519D82"><p>The server must support

the sharing of sessions. </p> </li>

<li id="GUID-AE8DF750-FABF-55CE-A633-41E96A50413B"><p>The connecting thread

can make the session sharable after creation, or it can create the session

as sharable. </p> </li>

<li id="GUID-E1962030-B977-5A90-AC3C-5419C2FAAF68"><p>Up to 255 threads can

be concurrently attached to a session. </p> </li>

</ul>

<section id="GUID-8C971096-BD4A-408A-AF20-15810FAB9D4C"><title>See also</title> <p> <xref href="GUID-1CC6FEF0-7D1E-5329-8276-22ACFE3DE362.dita">Subsessions

within a session</xref>  </p> </section>

</conbody></concept>