Chapter 1

Bootstrap code for a server should create an active scheduler, a cleanup stack, and a server
object; create a name for the server (stored in iName), and then issue Start() (or
StartL()) to cause the server to issue its first request. The server name must be specified
by any client wishing to connect to the server, as the aServer parameter to
RSessionBase::CreateSession().
The server's RunL() function renews the request to the kernel automatically. However, it
doesn't renew the request if (say) the session's ServiceL() function leaves. You have to
handle this from the active scheduler's Error() function, and issue ReStart() to renew
the request.
When the server handles a connect message, it invokes NewSessionL() to create a new
server-side CSharableSession-derived object. Oddly this function is const: you usually
need to cast away const-ness when you implement this function in order to be able to
increment usage counts and do other housekeeping in your derived server class.
When the server handles a disconnect message, it simply deletes the affected session,
which also causes its C++ destructor to be invoked.
Unlike in earlier versions of Symbian OS, the server does not store the message – it is
available to the session's ServiceL() routine and that must store it if necessary.
You can iterate through the sessions owned by the server, using the protected
iSessionIter member.
CSession and CSharableSession – a server-side session
In earlier versions of Symbian OS, the CSession class was used on the server side to
encapsulate a client-side session. The CSession class was thread-specific – that is, it was
owned by one thread on the client side. Symbian OS v6.x introduced sharable sessions with
the CSharable-Session class. A CSharableSession object can be shared between
multiple threads in the same process on the client side. When you design your server, you
can choose whether to provide sharable or unsharable sessions. Classes derived directly
from CSharableSession rather than from CSession will not be able to make use of the
thread-specific functions in CSession to transfer data between the server and the client
thread so it may be easier to derive from CSession if you do not need to share a session
between threads. Note that a sharable session requires the client-side session to call
Share() and possibly Attach() to actually be shared – these functions are described
under the RSessionBase class details.
The CSession class derives from CSharableSession and whichever you choose forms
the base class for the server side end of a session. You implement its ServiceL() function
to interpret and handle client requests. These classes also provide many convenience
functions for accessing the client and the current message. The relevant parts of
CSharableSession and CSession are
Class CSharableSession : public CBase
{
public:
friend class CServer;
IMPORT_C ~CSharableSession() =0;
IMPORT_C virtual void CreateL(const Cserver& aServer);