To allow realtime components to communicate, DSI defines requirements to the components and an interface that helps components to check for conformity of their peers. This section describes what DSI requires and provides with respect to realtime communication. In this section we assume to have realtime-components unless otherwise stated.
On connection setup, the traffic description of the intended connection is specified. This description is mainly a JCS-specification. It will be used to calculate buffer space and start offset of the connection to be created. Both the sender and the receiver must specify the same traffic description.
During data transfer, both components are responsible for meeting their traffic specification made on connection setup. This includes the bandwidth, the jitter and the packet rate. Obviously the components need a common time base, which is supported by DSI. It is left to the components to ascertain which data is valid according to the given time and the traffic specification of the connection.
- Todo:
- Support a common timebase by DSI. This includes the definition of a basic unit, a variable/function to get the time, functions to calculate the current/first/last packet and functions to tell if a packet is not yet/not any longer available.
If one components wants to compromise the other, the DSI API and its implementation behind cannot help to enforce metting the traffic description. However, the API supports the components in checking if the peer is well-behaving.
Following situations can happen:
- A send component, like a file provider, offers data at a certain bandwidth. The receiver consumes the data with a lower rate. It is not a fault of the receiver, it is the intended behaviour. The correct scenario might be to send in blocking mode, and to receive in nonblocking mode. If the receiver consumes data too fast, or the sender is too slow, the receiver will realize this when trying to get data.
- A send component, like a framegrabber driver, delivers data with a certain bandwidth. It cannot stop its dataflow. The receiver, e.g. a compressor, takes the data and converts it. The conversion process is non-interruptible, this may be the case with imported code from another project. If the receiver consumes the data slower than the sender sends, data will be overwritten after a certain time. At a result the data the receiver is currently working on gets corrupted. The solution DSI offers is to check a sequence number assigned to the data prior and after accessing it. If it turns out that the sender has overwritten the data while the receiver was operating on it, the computed result must be discarded. This optimistic approach requires the receiver to not getting confused by corrupted input data. But this is required anyway, if the sender is not trusted.
- Assume the same situation like above, but now the receiver is interuptible or can at least handle a signal. DSI allows to register a callback that is started if the sender reclaims data that is not acknowledged by the receiver.
- The send component, like a network device, delivers data with a certain bandwidth. The receiver is to slow, but does not want the sender to reclaim data the receiver did not acknowledge. DSI allows the sender to realize that the data is not acknowledged, so in turn it can discard the new data.
- Todo:
- Reclaiming data is currently not implemented. Implement it together with the according callback.
