Networking Scheduler API

Introduction

HydraNode Networking Scheduler is divided into three major parts:

User frontend

SSocket template class provides a generic typesafe frontend to users of the API. Providing accessors for all possible socket operations, it forwards all calls to the Translation Unit. No operations are performed in the frontend. Due to the template design of the frontend, we can have all possible socket functions declared there, but they won't get instanciated until they are actually used. As such, attempts to perform operations on sockets that do not have the specified operation defined will result in compile-time errors.

The underlying implementation for SSocket class is chosen based on the first two template parameters by default, however can be overridden by clients wishing to define their own underlying socket implementations.

The last parameter to SSocket template class is the scheduler class to use. This parameter is provided here merely for completeness, and is not allowed (nor recommended) to be overridden by module developers.

Translation Unit

The translation unit abstracts away the specifics of the underlying implementation of the sockets by wrapping the requests into generic objects, and submits them to the backend for processing when the time is ready. The Translation unit also handles data buffering and events from the underlying sockets. As such, it is also the driver of the scheduler engine. And last, but not least, it also bridges the backend and the frontend through virtual function and callback mechanisms. This unit is responsible for sending the actual I/O requests to the underlying socket implementation, as specified by the backend. No I/O may occour without explicit permission from the backend (implemented through virtual function mechanisms).

The backend

The backend works only using abstract request objects of types UploadReqBase, DownloadReqBase and ConnReqBase, and performs the I/O scheduling. The backend decides when a request may be fulfilled, and how much of the request may be fulfilled at this moment. Note that the backend also owns the request objects and is responsible for deleting those once they have been fulfilled.

Todo:
The Translation unit is useless overhead, and could be dropped in future versions; requests should be constructed only once, in SSocket class, and passed to SchedBase as ref-counted pointers to avoid excessive construction/destruction overheads.

Bug:
State variables aren't working in SSocket Since SSocket doesn't keep any information of it's own, and calls to implementation are passed through Request engine, queries on socket state right after issuing a function, e.g. connect() on it, return wrong state, since the call hasn't been passed to implementation yet. Possible fixes include setState method in implementation classes, or an additional state variable in SSocket class (latter is prefered).