nn::rdt Namespace

The RDT (reliable local communication) namespace.

Overview:The RDT library is a class library that uses the features of the UDS library to implement reliable data transmission (data sent reliably will not be corrupted or lost). The relationship between RDT and UDS can be likened to that of TCP and IP, with the former constructed atop the latter. RDT was designed to send and receive relatively large amounts of data (more than a few dozen KBs). It will not perform very well in situations in which small chunks of data (under 1 KB) are frequently being sent and received.

Sender class: Class that represents a device sending data. A Sender sends data to instances of the Receiver class (described below). The Sender class implements retransmission and other features that ensure that data that is sent will always be received, even if errors like packet loss occur during communication.

Receiver class: Class that represents a device receiving data. A Receiver class receives data from an instance of the aforementioned Sender class. The receiver continually sends ACKs (confirmatory responses) when appropriate and assembles the received data in the proper order.

UDS setup: Before an application can use RDT, it must first set up UDS. In other words, do not initialize the RDT library until a network has been created, the local host has connected to that network, and the transmission of data via UDS has become possible. Setting up UDS communication is the responsibility of the application. The same is true for dismantling the network that was created.

Features: The RDT class library involves a unidirectional flow of actual data from the Sender to the Receiver. If bidirectional communication is required, you must create another Sender/Receiver pair.

Non-blocking operation: Function calls in the RDT class library do not block. Calls to member functions like Sender::Open, Receiver::Wait, Sender::Send, and Receiver::Receive return immediately. The actual sending and receiving is handled by the Process function that has been provided for both classes.

Process function: Applications must call Process at intervals of at least every game frame. If Process is not called periodically, no actual communication or state transitions will take place. (Although a few functions, including Cancel, are exceptions to that rule.) You can sometimes improve the performance of send/receive operations by calling Process several times in a row.

Memory allocation: The RDT library does not allocate memory dynamically. Any memory required by the library must be provided to the library by the application when Initialize is called.
Note: When providing this memory, pay attention to its alignment.

Note:The RDT library implicitly consumes two nn::uds::EndpointDescriptor objects per each Sender or Receiver instance.

2010/06/14

Initial version.