tr udp
Module: tr_udp.c
The TR-UDP protocol is the UDP based protocol for real time communications that allows sending short messages with low latency and provides protocol reliability features. Formally, the TR-UDP protocol should fulfill the following requirements:
-
Low latency
- Send application message to its destination as soon as possible
- Receive and deliver message to application as soon as possible
-
Reliability
- Avoid losing messages
- In case of lost message, detect and recover it (time that takes to recover a message is related to both reliability and low latency requirements, so the protocol should pay a special attention to this issue)
- Handle messages reordering
Figure 1 (TR-UDP message header layout)
- Checksum (1 byte) the checksum of all bytes of the header
- Version (0.5 byte) fields allow the protocol to grow up. In future versions new functionalities could be added and the version fields will help peers to determine their compatibility. Recent version is 0.0.
- Type (0.5 byte): messages could be of type DATA(0x0), ACK(0x1) and RESET(0x2). The DATA messages are carrying payload. The RESET messages reset messages’ counter. The ACK messages are used to acknowledge the arrival of the DATA and RESET messages. The RESET and the ACK messages carry no payload.
- Payload length (2 byte) defines the number of bytes in the message payload.
- ID (4 byte) is a message serial number that sender assigns to DATA and RESET messages. The ACK messages must copy the ID from the corresponding DATA and RESET messages.
- Timestamp (4 byte) contains sending time of DATA and RESET messages and filled in by message sender. The ACK messages must copy the timestamp from the corresponding DATA and RESET messages.
The idea is quite simple. In order to know if message has arrived to its destination, it must be acknowledged by the receiver. The sender is storing the message in its memory as long as it is waiting for acknowledge. Once it gets acknowledge, the message can be discarded. In case the message is not acknowledged during some period of time, it must be retransmitted. Figure below visualizes the concept.
Figure 2 (Message retransmission)
When the sending operation is performed by application, the protocol engine does the following. First it assigns ID to the message and passes it to the sending module which, in turn, transmits the message to its destination. Then it adjusts retransmission timeout to the message and pushes it into queue of acknowledge pending messages (there is queue per channel). Whenever retransmission timeout of the message expires, the protocol engine retransmits the message (hands it over to the sender module) and sets a new timeout for the message. If acknowledge is received, the protocol engine is notified about it by receiver module. It examines the acknowledge pending messages and if acknowledge ID matches one of them, it removes the message from the queue and notifies application about successful delivery of the message (if application requested such notification). Figure below shows flow chart of outgoing messages processing in protocol engine.
Figure 3 (Sending messages flow chart)
The receiver module passes received messages to the protocol engine. If this is an acknowledge message then it is processed as described in the previous section. If this is a data message then the protocol engine must acknowledge it. So it generates acknowledge message and passes it to the sender module. Then it stores the received message till it is requested by application.
The protocol engine may get messages out of order because of retransmissions and routing (the last is less likely in closed real time system). So the engine put the messages into channel heap, ordered by messages ID-s. The engine knows what message is about to come next, so it should not pass out-of-order messages to application, but rather wait for the next in-order message. Of cause, some applications may do not care receiving messages out of order, so this behavior is configurable (out-of-order messages policy setting). The flow chart of incoming messages processing in protocol engine is shown in figure below.
Figure 4 (Receiving messages flow chart)
The TR-UDP protocol defines maximum message delay as a time that application permits for message delivering. Message latency is the actual time that it takes to transmit message; its value depends on network hardware and peers operating systems behavior. We assume that the maximum message delay is significantly bigger than average message latency and there is enough time for retransmissions. As a result, the timeout value of the retransmission timer becomes the most important parameter in the protocol configuration. To set a reasonable retransmission timeout, sender calculates average message RTT. It writes timestamp into message header and receiver copies the timestamp into corresponding ACK message, so the sender can calculate the RTT upon acknowledge receiving. Given the average RTT, the retransmission timeout could be set to average(RTT)+ε , where ε is a compensation for RTT jitter. Since the distribution of messages RTT-s could be considered as normal, the ε could be set to 2*σ, which covers over 97% of RTT-s. While average RTT and ε can be calculated during protocol work, the initial retransmission timeout must be set by application (initial retransmission timeout setting) and its value should be determined by benchmarking or theoretical computations. We refer to the timeout model that has been described above as average RTT retransmission model.
The average RTT retransmission model works well as long as number of channels is relatively small and losses of messages are sporadic over time and channels. Indeed, if some random message is lost, the protocol will retransmit it after average(RTT)+ ε timeout. Now consider a situation where message is lost over and over again. Once it exceeds its maximum message delay value, the protocol should not attempt to retransmit the message and, instead, proceed according to the message dropping policy setting. The setting allows application to configure the UDP-RT behavior for expired messages; the protocol can either silently discard these messages or declare system failure.
This document base on: http://www.codeproject.com/Articles/275715/Real-time-communications-over-UDP-protocol-UDP-RT