UDP (User Datagram Protocol) is a connectionless, unreliable transport-layer protocol in the IP suite that sends discrete packets called datagrams without establishing a session, guaranteeing delivery, or preserving order. It adds only source/destination port multiplexing and an optional checksum on top of raw IP, making it one of the lowest-overhead standard transports available on a TCP/IP stack.
In practice
UDP appears in embedded systems wherever low latency or low overhead matters more than guaranteed delivery. Typical uses include sensor telemetry streaming, audio/video over IP, device discovery (broadcast/multicast probes), NTP time synchronization, DNS lookups, TFTP firmware updates, and custom binary command-response protocols on local networks. On constrained MCUs running lwIP, uIP, or vendor-supplied stacks (e.g., the W5500 hardware TCP/IP offload chip, Microchip ENC28J60 with software stacks, or ESP32/ESP8266 with their SDK stacks), UDP is often preferred over TCP precisely because it avoids the memory and processing cost of connection-state machines and retransmission buffers.
Because UDP provides no delivery confirmation, the application must decide what to do with lost or reordered datagrams. For fire-and-forget telemetry this is acceptable. For reliable transfers such as TFTP or custom firmware loaders, the application layer adds its own sequence numbers, acknowledgments, and retransmit timers -- effectively reimplementing a stripped-down reliability mechanism. Getting that logic right is non-trivial; a common mistake is implementing retransmit without de-duplication, causing the receiver to process the same packet twice.
UDP datagrams carry 16-bit source and destination port numbers, a length field, and a 16-bit checksum that covers a pseudo-header (source IP, destination IP, protocol, length), the UDP header, and the payload. On IPv4, the checksum is technically optional -- a value of 0x0000 indicates it was not computed (note that a computed checksum which happens to equal zero is transmitted as 0xFFFF to avoid ambiguity) -- but most stacks compute it. On IPv6 the checksum is mandatory. The checksum uses the same one's-complement Internet checksum algorithm as TCP and IP, which catches many bit errors but does not provide strong error detection guarantees -- for safety-critical links, a stronger application-layer CRC is worth adding.
Broadcast and multicast are practical only with UDP for normal application data delivery (TCP does not support broadcast or multicast delivery semantics), making UDP the standard choice for zero-configuration discovery protocols like mDNS, SSDP, or custom device-announce schemes. On embedded targets sharing a LAN with many hosts, be careful about broadcast storms and about the stack's ability to filter or discard unwanted incoming datagrams quickly, since every broadcast is delivered up to the application layer and can wake an otherwise idle processor.
Frequently asked
When should I choose UDP over TCP in an embedded design?
Prefer UDP when: (1) you can tolerate lost packets (periodic sensor readings, log streams), (2)
latency matters more than completeness (audio, video, control loops), (3) you need broadcast or multicast, or (4) your
MCU's
RAM is too limited to maintain TCP connection state and retransmit buffers. Choose TCP when data must arrive intact and in order and you don't want to build your own reliability layer -- firmware update over a lossy WAN is a common case where TCP's overhead is justified.
Does UDP guarantee that a full datagram arrives intact, or can it arrive partially?
UDP is message-oriented, not stream-oriented. The IP layer either delivers the complete datagram to the UDP layer or drops it; there is no partial-datagram delivery visible to the application. However, datagrams can be silently dropped anywhere in the network, arrive out of order relative to other datagrams, or be duplicated. The UDP
checksum catches many (but not all) in-transit bit errors, but a corrupted datagram is simply discarded rather than retransmitted.
What is the maximum safe UDP payload size for most embedded Ethernet designs?
On a standard
Ethernet link (MTU 1500 bytes), the maximum UDP payload without IP fragmentation is 1472 bytes (1500 minus 20 bytes IP header minus 8 bytes UDP header). Staying at or below this limit is strongly advisable: IP fragmentation requires the receiver to reassemble fragments, many embedded stacks handle reassembly poorly or not at all, and a single lost fragment causes the entire datagram to be discarded. For Wi-Fi links subject to variable MTUs or VPN tunnels with overhead, using an even smaller payload (e.g., 1024 bytes) provides additional margin.
How do I receive UDP data on an embedded target without missing packets?
The main risks are
stack receive-buffer overflow and application polling being too slow. Use the largest socket receive buffer your
RAM budget allows, process incoming datagrams promptly (ideally from a dedicated task or a network
callback), and avoid doing slow work such as
flash writes inside the receive handler. On bare-metal targets, check whether your stack (e.g., lwIP in NO_SYS mode) requires you to poll a function like sys_check_timeouts() at regular intervals, or whether it is
interrupt-driven. Dropped packets at the socket layer are silent -- there is no TCP-style flow control to slow the sender.
Does UDP handle packet framing, or do I still need to frame my application messages?
UDP is already message-framed at the datagram level -- each successful sendto() call produces exactly one datagram, and each recvfrom() call retrieves at most one datagram (if the provided buffer is smaller than the arriving datagram, the datagram may be truncated or discarded depending on the
stack and API). Unlike TCP (a byte stream), you do not need to add your own length-prefix or delimiter framing to delineate message boundaries, as long as each logical message fits in a single datagram. If your message can span multiple datagrams, you will need application-level sequencing and reassembly.
Differentiators vs similar concepts
UDP is most commonly compared to TCP. TCP is connection-oriented and provides ordered, reliable, flow-controlled delivery of a byte stream, at the cost of connection handshake overhead, per-connection state (typically 1-4 KB of buffers and control structures), and added
latency from retransmission and congestion control. UDP is connectionless, sends independent datagrams with no delivery guarantee, and has near-zero per-connection state, making it faster to initiate and cheaper in memory. A subtler comparison is with raw IP sockets: UDP adds port-based multiplexing (so multiple applications can share one IP address) and the optional
checksum, while raw IP provides neither. UDP should not be confused with ICMP, which also runs directly over IP but is used for network diagnostics and error reporting, not application data transfer.
