TCP and UDP/Sending without promises/UDP: one card, one try
Lesson 3 of 12 · in 3D and VR

UDP: one card, one try

A UDP datagram is sent once. It arrives whole or not at all, and nothing in UDP resends it, orders it or removes a duplicate. That makes it the right choice when a newer datagram replaces an older one, and the wrong one when every byte has to arrive.

Lonely BinaryUpdated 2026-10-014 min readNo board required

View it in VR

Lesson 3 of the TCP and UDP course opens in a VR headset, on a table in front of you, and a voice starts three seconds after you arrive. Type this short address into the browser on a headset such as Meta Quest or Apple Vision Pro, and press Enter VR. No headset? Press Start the lesson: the same lesson, full screen.

learn.lonelybinary.com/vr/tcp-udp/3

A UDP send is one call and one datagram. The program hands UDP a block of bytes and a destination address and port, and UDP puts an eight-byte header in front and passes it to IP. The header has four 16-bit fields: source port, destination port, length and checksum. RFC 768 defines it.

Nothing else is added. There is no handshake before the first datagram and no acknowledgement after it. UDP keeps no record of what it sent, so it cannot send anything again. If a datagram is lost, nobody is told. If two arrive, the program sees two. If they arrive in the wrong order, the program sees the wrong order.

Cards that stand alone

This is a design, not a failure. It suits data in which each piece is complete in itself and a newer piece replaces an older one: the score of a match, whether a room is free, a temperature reading every few seconds. Resending an old reading would only get in the way of the new one.

The counter on the cards in the lesson shows how a program adds what UDP leaves out. The sender puts an increasing number on each card. The receiver keeps the highest it has seen, and ignores a card with a lower one. UDP did neither. Both are the program's own rules, and the program chooses how much to add: a counter, an acknowledgement, a resend after a timeout. A program that adds enough of them has rebuilt part of TCP, which is sometimes the right thing to do.

What it costs when it goes wrong

Loss is silent. A card that never arrives leaves no mark, and the receiver cannot know a card is missing unless the program numbers them. A sender that fires cards faster than the network or the receiver can take them loses some, and UDP has no feedback to say so.

The largest UDP payload over IPv4 is 65,507 bytes, but anything bigger than one link's limit gets fragmented, which is a bad idea. On Ethernet an IPv4 packet is at most 1,500 bytes. Keep each datagram small enough to travel in one piece.

On an ESP32

WiFiUDP sends with beginPacket, write and endPacket. The endPacket call returns 1 when lwIP has accepted the datagram, which says nothing about whether it left the radio, arrived or was read.

Common mistakes

  • Treating endPacket() returning 1 as delivery. It means the stack took the datagram.
  • Sending UDP when every byte has to arrive. A configuration file or a firmware image needs a repair that UDP does not give.
  • Assuming datagrams arrive in the order they were sent. Usually they do, on a quiet network. The program has to cope when they do not.

Edit this page — content/fundamentals/tcp-udp/udp-one-try.mdx

Discuss this article

Ask about this page. The answer stays here, on the page it belongs to, for whoever hits the same wall next.

Browse Fundamentals on the forum →