<?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>