Protocols::Generics::Session Class Reference
#include <Session.h> [code]
Inherited by Protocols::Generics::GenericSession.
Inheritance diagram for Protocols::Generics::Session:
[legend]List of all members.
Detailed Description
Interface
Session - Data objects exchange over a
Transport.
A common problem in any kind of communication protocols is the exchange of protocol data between two communicating parties. Common tasks:
- reading and buffering raw bytes until a complete logical protocol data unit is read
- parsing the raw representation of the logical data unit into a C++ object and forwarding this object for further processing to a higher-level handler that implements the protocol logic
- buffering outgoing C++ objects representing logical protocol data units until these could be written to the wire
- building a raw bytes representation of the protocol logical data units from the C++ object representation
- prioritazing or droping traffic in traffic congestion scenarios
The interface Session provides an abstraction for a generic solution to the above listed problems.
- Todo:
- Again as in DataSerializer, should we make the binding with Transport explicit? Maybe changing open() to open (Transport *). The session would then attach itself to Transport's TransportStatus?
- Todo:
- Switch to passing Transport * instead of Transport & (as a convention for differenciating between Value Objects and Reference Objects). That would require updating a few classes.
- Todo:
- Should each Interface interface has a method setStatus (InterfaceStatus *), which would allow us to change the listener at runtime? For example, a HandshakingSession could register as a TransportStatus first and once handshaking is finished, a PacketSession would register itself using setStatus (this).
- Todo:
- Currently we only have unicast status notifications. What about multicast notifications? We could use an adapter for such scenarios. Such an adaptor will have to be manually implemented. It seems like clearer design to prefer unicast notifications. See for example GenericSession. It listens to TransportStatus and reacts on its signals. GenericSession is a kind of controller that then delegates functionality to other helper objects (e.g. DataSerializer). I have a feeling that using multicast notifications and having both GenericSession and DataSerializer reacting on the notifications would make the design more complex (e.g. DataSerializer would probably need a status interface too and it is not clear whi is "in control").
Definition at line 78 of file Session.h.
|
Public Member Functions |
| virtual | ~Session () |
| virtual void | open ()=0 |
| | Opens the session for writing and starts reading Data.
|
| virtual void | send (const Data &)=0 |
| | Enqueues and eventually sends data.
|
| virtual void | close ()=0 |
| | Closes Session for writing.
|
| virtual void | abort ()=0 |
| | Immediately closes the Session.
|
Constructor & Destructor Documentation
| virtual Protocols::Generics::Session::~Session |
( |
|
) |
[inline, virtual] |
|
Member Function Documentation
| void Session::abort |
( |
|
) |
[pure virtual] |
|
| void Session::close |
( |
|
) |
[pure virtual] |
|
| void Session::open |
( |
|
) |
[pure virtual] |
|
| void Session::send |
( |
const Data & |
data |
) |
[pure virtual] |
|
|
|
Enqueues and eventually sends data.
- Parameters:
-
The object data will be enqueued and will be actually sent as soon as possible.
Implemented in Protocols::Generics::GenericSession. |
The documentation for this class was generated from the following files: