<?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-D0D27AEA-FDDB-5F6F-94F6-ADDF5910DC47" xml:lang="en"><title>Client/Server

Overview</title><prolog><metadata><keywords/></metadata></prolog><conbody>

<section id="GUID-CA831E24-1BE6-4D18-889A-CD78364828C9"><title>Purpose</title> <p>Provides the Symbian platform client/server

framework, by which a program can offer services to multiple other programs.

Servers also handle resources on behalf of multiple clients.</p> <p>All Symbian

platform developers should have a general understanding of this API in order

to understand the design of many Symbian platform system APIs. In specialized

circumstances, developers may also create their own server programs.</p> </section>

<section id="GUID-539EF180-E0B7-4931-B1DC-BA7801D54F9F"><title>Architectural relationships</title> <p>Many important Symbian

platform system APIs use the client/server framework to provide services to

client programs: for example, the Windows Server, File Server, and Messaging.

In some cases, such APIs provide extensive client-side classes that hide the

direct use of the client/server interface from the client program.</p> </section>

<section id="GUID-8163FC8D-F044-46D5-8806-13C8F22677A1"><title>Description</title> <p>The API has four key concepts: server

(<codeph>CServer2</codeph>), session (<codeph>CSession2</codeph> and <codeph>RSessionBase</codeph>),

sub-session (<codeph>RSubSessionBase</codeph>), and message (<codeph>RMessage2</codeph>,

and <codeph>RMessagePtr2</codeph>). </p> <p><b>General

properties</b> </p> <p>A server program offers services to other processes

through a client interface API that it defines. Clients and servers use a

message passing protocol to communicate.</p> <p>Client/server is usually chosen,

rather than a conventional shared library, to provide services when one or

more of the following is required:</p> <ul>

<li id="GUID-7083F154-725B-5133-8391-41BBA67341E9"><p>management of shared

system resource</p> </li>

<li id="GUID-5C655C17-036C-50CD-BEE6-45C1A261FEC3"><p>asynchronous services</p> </li>

<li id="GUID-AD3A0E0E-A4EB-5F50-8F9E-A906591839A6"><p>the protection offered

by running in a separate process from clients.</p> </li>

</ul> <p>A client/server implementation supplies a server program executable,

and a <filepath>.DLL</filepath> containing the client-side interface.</p> <p><b>Server</b> </p> <p>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. </p> <p>The base server interface is provided by <xref href="GUID-8E316AC4-4676-301A-9A23-659E83AA1D1C.dita"><apiname>CServer2</apiname></xref>.</p> <p><b>Session</b> </p> <p>The session is the channel of communication between

a client and a server. </p> <p>The base client-side session interface is provided

by <xref href="GUID-6D8A458C-9A39-3000-A3BC-060A2A3663E6.dita"><apiname>RSessionBase</apiname></xref>. An implementation derives from this to

define the functions that it wants to expose to clients.</p> <p>The corresponding

server-side session base classes is <xref href="GUID-D5A30C75-E22C-34E8-913B-7D2CA6AD5C51.dita"><apiname>CSession2</apiname></xref>. 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.</p> <p><b>Sub-session</b> </p> <p>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.</p> <p>The

base client-side sub-session interface is provided by <xref href="GUID-1BBE1448-1DF8-33C4-BF9E-5A5F427AEE35.dita"><apiname>RSubSessionBase</apiname></xref>.

An implementation derives from this to define the functions that it wants

to expose to clients.</p> <p>A server implements a corresponding sub-session

class based on <xref href="GUID-9230EF62-376A-389C-B720-7C1EDCB7EA97.dita"><apiname>CObject</apiname></xref>, <xref href="GUID-DE901A59-C714-356A-9490-C4E9C9F186DB.dita"><apiname>CObjectCon</apiname></xref> and <xref href="GUID-70824EE4-9E01-3AC0-9318-4B521A1FDD5E.dita"><apiname>CObjectIx</apiname></xref>,

the Reference Counting Objects API.</p> <p><b>Message</b> </p> <p>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.</p> <p>Clients do not use messages

directly; they use a <xref href="GUID-4AD02F14-1142-372F-9D11-224595932034.dita"><apiname>TIpcArgs</apiname></xref> object to package the message

information that is to be sent to the server.</p> <p>Server-side sessions

and subsessions access this information through an <xref href="GUID-D7D422D3-65E5-378B-8F52-6485BC5603A0.dita"><apiname>RMessage2</apiname></xref> object. </p> </section>

<section id="GUID-74655E18-CC4C-4432-A8F3-BADFCA5CB7D2"><title>See also</title> <p><xref href="GUID-E189B0C0-AAB5-5472-996B-91043DE0B6D4.dita">Package

Buffers Overview</xref> </p> <p><xref href="GUID-BE0C94BE-94F0-54B3-8674-366C09261E5D.dita">Reference

Counting Objects Overview</xref> </p> <p><xref href="GUID-547CF71C-6A62-57C0-A9BE-E76B4286C6D6.dita">Threads

And Processes Overview</xref> </p> </section>

</conbody></concept>