Reliable User Datagram Protocol - RUDP

Reliable UDP (RUDP) is a protocol built on top of UDP that adds reliability features like acknowledgments, retransmissions and ordered delivery - all while keeping UDP’s low-latency benefits. When it comes to sending data across the internet, we often face a trade-off between speed and reliability.

• UDP (User Datagram Protocol) is fast but unreliable.
• TCP (Transmission Control Protocol) is reliable but slower due to its connection setup and acknowledgment mechanisms.

Note: Think of it as "UDP + reliability layer", making it suitable for high-speed, real-time applications (like gaming, streaming and VoIP) that can’t afford TCP’s connection overhead but still need dependable delivery.

Why UDP Alone Isn’t Enough

UDP sends data packets (called datagrams) directly from sender to receiver without any handshake or confirmation. This means:

• Packets can be lost, duplicated or arrive out of order.
• There’s no acknowledgment from the receiver.
• The sender doesn’t know whether data arrived.

Note: RUDP fixes these issues by introducing a reliability layer on top of UDP - a smart middle ground.

RUDP Architecture - How It Works

RUDP sits in the application layer, built over UDP. Both the sender and receiver maintain a window of packets - a fixed-size range that controls how many packets can be sent or received at a time. Here’s how it flows:

1. Sender breaks the message into smaller segments.
2. Each segment is assigned a sequence number and checksum (to verify data integrity).
3. Packets are sent through the RUDP protocol over UDP.
4. The receiver checks for errors and order, sends ACKs (acknowledgments) and buffers packets until all are received correctly.
5. If an ACK isn’t received within a timeout, the sender retransmits that packet.

Note: This system ensures reliability - but without TCP’s heavy connection setup.

Key Components of RUDP

1. Thread-Safe Buffers

Both sender and receiver use synchronized shared buffers protected by semaphores to prevent multiple threads from accessing data simultaneously - avoiding deadlocks and corruption.

2. Window Management

Two important counters manage the flow:

• base - the sequence number of the earliest unacknowledged packet
• next - the sequence number of the next packet to send

Note: This allows efficient tracking of which packets are "in-flight" and which are confirmed.

3. Timeout and Retransmission

• Each sent packet starts a timer.
• If an acknowledgment doesn’t arrive before the timer expires, the sender automatically resends that packet.
• This guarantees that no data is permanently lost.

4. Network Simulation & Queuing

• RUDP can simulate network delays, losses and out-of-order packets during testing.
• Each packet is queued with a timestamp (current_time + delay) to mimic real-world conditions.

Sliding Window Protocol - The Core of RUDP Reliability

The Sliding Window Protocol (SWP) is the heart of RUDP. It ensures that:

• Packets are sent in a controlled, continuous flow.
• Acknowledgments shift the "window" forward as packets are received.
• Duplicates and out-of-order packets are discarded or reordered.

Types:

1. One-Bit Sliding Window Protocol – simplest, only one packet in transit.
2. Go-Back-N Protocol – retransmits all packets after a loss.
3. Selective Repeat Protocol – retransmits only the lost packet (most efficient, used in RUDP).

Piggybacking Technique

• Instead of sending separate acknowledgment packets, RUDP uses piggybacking - attaching ACKs to outgoing data packets.
• This reduces network overhead and improves performance, especially in bidirectional communication.

Mathematical View of Window Updates

• Each time a packet is acknowledged, the window’s upper edge moves forward.
• When all outstanding packets are acknowledged, the sender knows all data was received - and the connection can safely close.
• This math-driven management helps RUDP balance speed (via windowing) and reliability (via acknowledgments).

Internal Classes in RUDP

RUDP Work Flow

Client Side

1. Data is divided into segments.
2. Each segment gets a frame (sequence number + checksum).
3. Sent using Support_RUDP.send_udp().
4. Timer starts for each segment.
5. If ACK is received - mark as delivered.
6. If timeout occurs - resend packet.

Server Side

1. Listens for incoming packets.
2. Validates checksum and sequence number.
3. Sends ACK for each valid packet.
4. Reorders any out-of-sequence packets.
5. Delivers final data to the application once all are received.

Pseudo Code for RUDP Class

Class RUDP{
//setting up the window sizes
set Receiver Window size
set Sender Window size
start receiver thread that receives the aka(Acknowledgment) and data for both the receiver and the sender
//sender calls
sent_data(byte[] data_gram, int size)
{
//process flow => data -> segments -> store into sender buffer -> send -> start timer
//breaking into segments and sending along with frames
Divide into the segments.
put every segment into the sender's buffer
segment sending using sent_udp() of support_RUDP class
timeout scheduling for the data that is divided into segments using frames
}
//receiver calls
receive_data(byte[] buffer, int size)
{
//receiving of the segments of the data packets
segment receiving once at a time including the frames
}
//call by both the sender and receiver
close()
{
//creation of flag for the indication
creation of a flag segment to indicate the data transfer status
//verification of the data
//if data receiving completed -> close
once the complete data is received close the segment
}
}
//RUDP class ends here

Pseudo Code of Thread_receiver Class

Class Thread_receiver
{
while(true)
{
//waiting for the packet -> received
Receive the packet from socket
//numberize or make checksum of the data
individualize a segment from the packet that is received
//verification of the data
checksum verification that is sent along the frames
if segment contains acknowledgment
process -> remove segments from the sender's buffer
if segment contains data
put data->receiver's buffer
send acknowledgment
}
}
//end of Thread_receiver Class

Pseudo Code for Support_RUDP Class

Class Support_RUDP
{
//simulate over the conditions that can cause the segments not received completely
random network delay
network loss
any other potential that can effect the packet
//process
packets from the segments received processing
//sent
sent the data packet over the socket
}
//end of Support_RUDP class

Pseudo Code for Client-Server Class
//Sender
Class Client{
RUDP rudp = new RUDP(Host_name, Port, Local);
//send the data
rudp.send();
//close
rudp.close();
}
//client class end
//Receiver Class start
Class Server{
RUDP rudp = new RUDP(Host_name, Port, Local);
//receive the data
rudp.receive();
//close
rudp.close();
}

Use Cases of RUDP

• Online gaming: where latency must be minimal but some reliability is needed.
• VoIP and video streaming: where real-time communication is key, but lost packets can degrade quality.
• IoT systems: where lightweight and resilient communication is necessary.

RUDP vs UDP vs TCP