Subsessions within a session
Describes subsessions within a session.
Once a client has established a session with a server, it can then establish a number of subsessions with that server. Each subsession represents an independent channel of communication within the current session.
Subsessions are useful if a single client needs to establish many channels of communication with the server. This is because subsessions have a much lower overhead than a full session. The main cost of a subsession is slightly increased programming complexity on the server side.
The main points are:
the client has an
RSubSessionBasehandle to the subsessionthe server uses a
CObjectderived class to represent the subsession.
As a subsession is always referenced by a handle on the client side, the corresponding subsession object on the server side must generate a handle.
For ordinary sessions, the generation of handles is done by the server framework.
For subsessions, server side code must be explicitly written to do this.
The CObject class and its associated container (CObjectCon)
and index (CObjectIx) classes provide the behaviour to achieve
this.
Server side requirements
Each subsession is represented
by an instance of a CObject derived class.
Subsession
objects must be held in an object container, an instance of CObjectCon.
This means that the server 's CServer2 derived class must
construct and maintain a CObjectCon object.
Object
containers are constructed by and held in an object container index, an instance
of a CObjectConIx. This means that the server 's CServer2 derived
class must construct and maintain a CObjectConIx object.
A
unique handle number for a subsession object is generated when the subsession
object is added to an object index, an instance of a CObjectIx.
This means that the server's CServer2 derived class must
construct and maintain a CObjectIx object.
The handle number is a combination of a unique id assigned to the object's container and a number generated by the object index.
Subsession within a session