Building Reliable UDP

Building Reliable UDP: A Guide to Enhancing UDP's Limitations

Most developers default to using TCP when considering networking. This is because TCP guarantees data integrity, order, and delivery. However, there are instances where UDP is preferred, such as online multiplayer games, live video streaming, voice-over-IP, DNS, IoT devices, and real-time telemetry. The reason for this choice lies in UDP's ability to provide developers with control over the protocol, optimizing it for their specific application needs.

Reliable UDP is not a separate protocol but an engineering pattern that rebuilds some TCP capabilities, only the ones necessary for the application. Let's create reliable UDP from scratch by understanding UDP, its advantages, and its drawbacks.

Understanding UDP

Imagine tossing a letter into the wind, hoping it reaches its destination. This represents UDP. With no handshakes, confirmations, or guarantees, UDP simply sends packets into the network, hoping for the best. Despite these limitations, UDP offers significant benefits, particularly in situations where guarantees come at a cost. TCP introduces connection setup, congestion control, flow control, retransmissions, ordered delivery, and head-of-line blocking. While these features are essential in certain scenarios, they can be unnecessary in others.

Why Would Anyone Use UDP?

The decision to use UDP instead of TCP is often puzzling. After all, UDP doesn't guarantee delivery, order, or prevent duplicates. It doesn't even ensure that a receiver exists. This seems terrifying, but engineers choose UDP because it provides them with something invaluable: control. Instead of accepting TCP's built-in reliability mechanisms, developers can design their own, tailored to their specific application needs.

Designing Reliable UDP

To create reliable UDP, we'll design and implement several mechanisms that transform UDP into a dependable transport layer. These mechanisms include sequence numbers, acknowledgements, retransmissions, timeouts, sliding windows, duplicate detection, and packet ordering.

Packet Structure

Our first step is to design a custom packet format. The packet will consist of the following fields:

+--------------------------------+ | Sequence Number | +--------------------------------+ | Acknowledgement | +--------------------------------+ | Flags | +--------------------------------+ | Payload | +--------------------------------+

Each field serves a specific purpose, such as tracking sequence numbers, acknowledgements, and duplicate detection.

Rust Representation

pub struct Packet {

pub sequence : u32 ,

pub acknowledgement : u32 ,

pub flags : u8 ,

pub payload : Vec < u8 > ,

}

Acknowledgements

The receiver confirms successful delivery of packets by sending acknowledgements. The sender removes the acknowledged packet from memory, ensuring efficient communication.

Retransmissions

To handle lost packets, the sender starts a retransmission timer for each sent packet. If an acknowledgement is not received within the timeout period, the sender resends the packet. This mechanism significantly improves reliability.

Timeouts

Choosing appropriate timeout values is crucial for maintaining optimal performance. Too short, and unnecessary retransmissions occur. Too long, and recovery becomes slow. Typical timeout values range from 500 ms to several seconds, and adaptive protocols dynamically adjust these values based on network conditions.

Duplicate Detection

Networks sometimes duplicate packets, leading to potential issues. To handle duplicate packets, the receiver maintains a set of processed sequence numbers. If an incoming packet's sequence number is already present in the set, it is ignored, ensuring that only unique packets are processed.

Packet Ordering

In some cases, packets may arrive out of order. To address this issue, we maintain a buffer that stores incoming packets. Once the buffer is filled, the packets are sorted based on their sequence numbers before delivery to the application. This ensures that the application receives packets in the correct order, regardless of the order they arrived in.