UDP and Packet Loss: Strategies for Handling It

UDP doesn't recover lost packets. That's not a bug—it's the whole point.

TCP treats every lost packet as a crisis, halting transmission until the gap is filled. For a file download, that's exactly right. For a video call, it's catastrophic. A video frame from 500 milliseconds ago is useless if it arrives now—the viewer has already moved on. Similarly, in a multiplayer game, knowing where a player was half a second ago doesn't help when you need to know where they are right now.

UDP's philosophy: send it and forget it. No connection state, no tracking, no recovery. This makes UDP fast, but it also means packet loss is your problem. The right solution depends entirely on what you're building.

Detecting Loss with Sequence Numbers

Before you can handle packet loss, you need to know it's happening.

Add a sequence number to every packet—a counter that increments with each send. When your receiver sees packet 1,043 arrive after packet 1,041, it knows immediately that packet 1,042 vanished somewhere in transit. The gap tells you exactly how many packets disappeared.

Sequence numbers also catch duplicates (networks occasionally clone packets) and reordering (packet 1,045 arriving before 1,044). For streaming data, they let you reconstruct proper order even when the network scrambles delivery.

Implementation is simple: add a 32-bit or 64-bit field to your packet header. The sender increments it for each packet. The receiver tracks what it's seen. Any gap means loss.

Selective Recovery with Acknowledgments

Some UDP applications build their own acknowledgment systems, borrowing from TCP but adapting to real-time constraints.

The receiver periodically sends back status reports: "I received packets 1,040-1,042 and 1,044-1,048, but I'm missing 1,043." The sender then decides whether retransmitting 1,043 makes sense. If it contained a chat message, absolutely retransmit. If it contained one frame in a 60-fps video stream, the moment has passed.

The key difference from TCP: these acknowledgment systems understand what the data represents. They make intelligent decisions about whether recovery is worthwhile. They also batch acknowledgments to reduce overhead—one acknowledgment per hundred packets rather than one per packet.

Preventing Loss with Forward Error Correction

Forward Error Correction (FEC) doesn't wait for loss to happen. It sends redundant data proactively, allowing the receiver to reconstruct lost packets without asking for retransmission.

Think of it as including the answer key along with the test—if part of the test gets lost, you can still figure out what was there.

The simplest FEC technique: XOR packets 1-4 together and send the result as packet 5. If any single packet from that group goes missing, XOR the survivors with the parity packet to recreate it. More sophisticated schemes like Reed-Solomon codes can recover from multiple losses within a block.

FEC shines for one-way communication or high-latency links. Satellite broadcasts use it extensively—asking for retransmission over a satellite link would add seconds of delay. The trade-off is bandwidth: you're sending extra data even when the network is perfect. Adaptive FEC adjusts redundancy based on observed loss rates.

Sending Data Twice

Sometimes the simplest approach wins: send important data multiple times.

VoIP applications might transmit each audio packet twice with a slight offset. If one copy gets lost, the other probably arrives. This differs from retransmission—both copies go out immediately, not after detecting loss.

Effectiveness depends on whether losses are independent. Random, uncorrelated losses? Sending twice dramatically reduces the chance both copies vanish. Burst losses from a congested router? Less helpful.

Many real-time applications use partial redundancy: include a low-quality copy of previous data alongside current data. A VoIP packet might carry high-quality audio for the current 20ms plus low-quality audio for the previous 20ms. If the previous packet was lost, the backup fills the gap.

Hiding Loss with Prediction

For continuous motion or audio, sometimes the best response to loss is an educated guess.

Video packets 100 and 102 arrive, but 101 is lost. Interpolate—generate a frame halfway between 100 and 102. For slow-moving scenes, this is often imperceptible.

Game clients predict constantly. If the server sends player positions every 50ms and a packet vanishes, the client extrapolates from last known position and velocity. When the next update arrives, it smoothly corrects any drift. The game feels responsive even during brief outages.

Audio applications synthesize missing chunks by repeating or blending adjacent audio. A lost 20ms of speech during a vowel sound? Often undetectable.

Choosing Your Strategy

Three questions determine the right approach:

How time-sensitive is this data? A chat message can wait for retransmission. A live video frame cannot.

What's the impact of loss? A dropped frame in 60fps video is invisible. A dropped "player scored" event breaks the game state.

What's the cost of recovery? FEC burns bandwidth constantly. Retransmission adds latency. Prediction requires computation.

Real-time video streaming typically accepts loss—skip the missing frame, keep playing. The brief glitch beats pausing for retransmission.

High-speed file transfer over UDP requires perfect delivery, but can retransmit aggressively—multiple simultaneous requests rather than waiting for timeouts.

Multiplayer games use a hybrid: player positions stream without acknowledgment (the next update arrives shortly anyway), but critical events like "weapon acquired" or "point scored" get acknowledged and retransmitted. Those state changes can't be guessed.