<?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-67718111-07FB-59CC-A9C2-86593F868C2C" xml:lang="en"><title>Features

of the client-server architecture</title><shortdesc>Describes the features of the client-server architecture.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<section id="GUID-733332EE-A689-4D9A-AAE3-3980B915412B"><title>Context</title> <p>Each session maintains its own context.

This allows sessions to be owned by different active objects within the same

thread, by different components within the same thread, etc., without interference. </p> </section>

<section id="GUID-35A7DB04-C9D5-47FF-A793-29533CD766A4"><title>Context switching</title> <p>Client-server communication requires

context switching: </p> <ul>

<li id="GUID-50EC1E74-44B3-52C7-A2E0-CA129561E25B"><p>messages are sent via

the Kernel </p> </li>

<li id="GUID-94E8A131-0E5C-5034-A903-E903A1121954"><p>handling the message

involves a switch from client thread, to server thread, and back to client

thread </p> </li>

<li id="GUID-702DA432-6985-5046-92EB-C3159EAE7C2A"><p>inter-thread data transfer

can never be done with simple C++ pointers: it always involves data copying.

Furthermore, it may involve cross-address-space data transfer, if the threads

are in different processes. </p> </li>

</ul> <p>Compared with a simple function call or memory copy, context switching

is a relatively expensive operation, and should be minimised. Servers whose

performance is critical use buffering to minimise context switches. Sometimes,

this is transparent. Often, the client interface design is affected by the

requirement for buffering. </p> </section>

<section id="GUID-BC1416C3-DD32-438E-A574-21802747220B"><title>Thread-based</title> <p>The basic architecture of servers

is thread-based. This gives the implementers of a system the flexibility to

package the server threads into whatever processes they choose, depending

on the balance of requirements for security and economy. </p> <p>This can

be contrasted with other systems in which all, or most, servers run as part

of the Kernel. On Symbian platform this is not necessary, so security is better. </p> <p>Client-server

policies can be contrasted with systems which require servers to have their

own process. This uses more memory (e.g. for address translation tables),

and has worse performance (inter-thread data transfer involves translation

as well as copying). </p> </section>

<section id="GUID-15B1DC2E-AB35-48DB-8EC4-11127DF974B0"><title>Cleanup</title> <p>When a client process terminates, all server

resources associated with it should be cleaned up. </p> <p>When a session

is ended, servers must clean up all objects associated with it, and clients

must consider any handles associated with it as invalid, and perform any necessary

client-side cleanup. </p> <p>For a non-sharable session, if the client thread

dies, then the Kernel performs thread-death cleanup and sends a disconnect

message to the server end of all sessions associated with that client thread. </p> <p>For

a sharable session, the death of any or all client threads does not trigger

closure of the session. This is because the session is process relative. To

close a shared session, either the process must terminate, or the session

must be explicitly closed through a client side call to <codeph>Close()</codeph> on

the client-side session handle, <codeph>RSessionBase</codeph>. </p> </section>

</conbody></concept>