Protocols::Generics::Transport Class Reference
#include <Transport.h> [code]
Inherits Protocols::Generics::Connection, and Protocols::Generics::Buffer.
Inherited by Protocols::Generics::SocketTransport, and Protocols::Generics::Testing::TransportStub.
Inheritance diagram for Protocols::Generics::Transport:
Detailed Description
Interface for a low-level transport protocol.A Transport is a Connection with a built-in Buffer.
Typically each application layer protocol (TCP/IP suite) is bound to using either TCP or UDP transport. For the sake of extensibility we at Calitko would like to be able to easily change transports and for example run HTTP on top of a custom UDP-based transport protocol (e.g. make NAT to NAT transfers possible, or to run Gnutella over UDP instead of TCP).
The classical socket interface requires users to implement a mechanism for buffering incoming or outgoing data until a complete information unit (e.g. packet) has been received or sent. User code can be largely simplified by guaranteeing that a certain number of bytes can be read or written via the Transport. The clients can thus buffer only higher level representation of their data (as C++ objects) and write/read each one as raw bytes in a single call to Transport. High level implementation would not need to care about buffering raw data anymore. Hence, a Transport implementation will manage internal read and write buffers. Take a look at the functions peek(), peekTo(), peekAll(), read(), readTo(), readAll() and write().
Since concrete protocols may be either stream oriented or datagram oriented, the data read/write interface of Connection should provide for unambiguous interpretation how the raw data should be arranged in datagrams. The flush flag of write() can be used to give the transport a clue where is the end of a packet for example. Then all buffered data between flushes will be written in a single datagram. When reading packets send over datagram based transports, the transport may validate the packet headers to make sure that the packet could correctly be extracted from the sequential interface of Transport.
- Todo:
- Most network operations have some time constraints and associated timeout intervals (connect/disconnect/read/write). To simplify implementation of application protocols, we could probably have a decorator or a proxy take care of these timeouts.
- Todo:
- Sometimes it is necessary to limit the upload and download bandwidth of a connections. That could be realized using a ThrottledTransport proxying to the real Transport. The proxy would limit the amount of data that can be read or written per second and if the channel is saturated it will emit the signals readyRead() and bytesWritten() once a second to keep up the transfer rate.
Definition at line 79 of file Transport.h.
Public Member Functions | |
| virtual | ~Transport () |
| virtual void | setTransportStatus (TransportStatus *)=0 |
Constructor & Destructor Documentation
|
|
Definition at line 84 of file Transport.h. |
Member Function Documentation
|
|
Implemented in Protocols::Generics::SocketTransport, and Protocols::Generics::Testing::TransportStub. |
The documentation for this class was generated from the following file:
- Protocols/Generics/Transport.h