3 User Datagram Protocol (UDP)

3.1 Start With One Datagram

Decide What One Missing Message Means

Picture a greenhouse node sending soil status every thirty seconds. Most readings can be replaced by the next one, but a valve command cannot. The product owner must decide which messages may be lost, late, repeated, or out of order before choosing the light send-and-forget path.

Write a receiver rule for each message type. Name its source, event time, sequence, useful lifetime, allowed repeats, and the state it may change. State whether the next reading replaces a missing one, whether the sender retries, and how the receiver rejects an old command.

Inject loss, delay, duplication, reorder, a restarted sender, a restarted receiver, and a false source. Watch both ends. Check that routine status stays useful, alarms become visible, repeated work is safe, and commands cannot act twice or after their deadline. Measure the extra energy and delay of any repair rule.

Keep urgent control near the greenhouse when a missed remote exchange could harm crops or people. A distant store may collect trends, but it must not be the only place that knows whether a valve may open. Reachability alone does not prove trust.

This opening does not choose the right transport for every message. Practitioner writes and tests the receiver contract. Under the Hood examines checksums, ports, message size, loss, ordering, repair, and the security work that sits above the small datagram boundary.

Picture a battery sensor sending one small reading and then going back to sleep. UDP makes that send cheap, but it also leaves delivery, ordering, retry, and acceptance decisions outside the transport itself. The useful question is not whether UDP is simple; it is whether the application record can tolerate what UDP does not promise.

3.2 Overview: UDP Is a Datagram Boundary

UDP is a connectionless transport protocol. It adds source port, destination port, length, and checksum information to application data, then sends each message as an independent datagram without first creating a transport session.

That small transport boundary can be a good fit for IoT traffic when each message has bounded meaning. A routine reading can often be replaced by the next reading. A discovery request may need to reach more than one local endpoint. An application protocol such as CoAP can add acknowledgement behavior only where it is needed.

For example, a greenhouse node might send soil-moisture status every 30 seconds with a sample time and sequence number. If packet 181 is missing but packet 182 arrives within the dashboard freshness window, the receiver can show the newer value and mark the older sample as skipped. That is a reasonable UDP story only because the record names the receiver behavior. The same node's irrigation command would need a different record, because a missed, repeated, or late command can change equipment state.

UDP therefore works best when the review names the message consequence. Replaceable telemetry, local discovery, and one-shot diagnostic events often have tolerances that can be written down. Commands, alarms, billing records, and audit events usually need acknowledgement, identifiers, replay controls, or a different transport pattern. The protocol choice follows the receiver contract, not the other way around.

UDP’s appeal and its limit are easiest to see in one exchange. Inspect Figure 3.1 before assigning reliability responsibilities to the application.

Read Figure 3.1 from the client datagram to the server, then notice the deliberately absent connection setup and transport acknowledgement path. The small header and independent message boundary reduce transport work, but loss, ordering, duplication, backoff, and application confirmation remain outside that promise. This is the boundary the rest of the chapter uses to build a receiver contract rather than calling UDP simply reliable or unreliable.

Overview Check

3.3 Practitioner: Write the Receiver Contract

Before selecting UDP, write the receiver contract. Name the message purpose, endpoint roles, freshness rule, duplicate behavior, retry ownership, validation boundary, and operational evidence. This turns UDP from a vague preference into a bounded design choice.

The same device can use UDP for routine status while using a different acknowledgement path for commands, configuration, or firmware transfer. Do not copy the UDP decision from one flow to another unless the receiver contract is still true.

A practical contract should be testable from both sides of the path. For a parking-space sensor, the sender record might show datagram ID, sample time, payload schema, destination service, and retry timer. The receiver record should show whether a newer reading replaces an older one, how duplicate IDs are ignored, when a space state becomes stale, and which alert appears if no fresh sample arrives before the timeout.

The contract also needs an owner. If a gateway retries above UDP, the gateway owns retry spacing and duplicate risk. If the device retries, the device owns power cost and stale-message rejection. If the operator accepts loss for a dashboard-only flow, the monitoring system owns the stale-data alarm. Without that owner, UDP failures become invisible until a user notices incorrect state.

Practitioner Check

3.4 Under the Hood: What UDP Does Not Promise

UDP provides port multiplexing, a datagram boundary, length information, and checksum-based corruption detection. It does not create a reliable ordered stream, maintain connection state, confirm delivery, retransmit missing data, suppress duplicates, or apply transport-level flow control.

The checksum is not a security boundary. It can help detect accidental corruption, but it does not authenticate the peer, encrypt the payload, authorize an action, or prevent replay. Protected UDP paths need a separate security review, often at the application or DTLS layer, and commands with side effects need acknowledgement, identifiers, idempotent handling, or a clear failure policy above UDP.

Datagram boundaries are useful because the receiver knows where one UDP payload ends. They are not the same as a business event boundary. A receiver may parse the datagram and still reject it as stale, unauthenticated, duplicated, outside a safety window, or inconsistent with the current device state. Under-the-hood review should therefore ask which field carries identity or freshness, which check rejects repeats, and where rejected datagrams are logged.

UDP also lacks built-in congestion and backpressure behavior. A burst of retries, discovery responses, or telemetry reports can overload a gateway even though each datagram is individually small. The design evidence should name rate limits, retry backoff, multicast response spreading, queue policy, or alarm behavior. If nobody owns those controls, the UDP decision is incomplete even when every single datagram format is valid.

UDP flood: state abuse without a connection

UDP has no listen backlog to exhaust, but a flood can still consume ingress bandwidth, receive-queue space, packet-processing time, and response bandwidth. In the classic closed-port pattern, an attacker sends datagrams across many destination ports, often with a forged source address. The host must inspect each datagram; for a closed port, the IP layer may generate an ICMP Port Unreachable response toward the forged address. The victim then spends both receive and transmit capacity on traffic that never represented a valid application exchange.

1. Arrival: a high-rate datagram stream reaches open and closed UDP ports.
2. Demultiplex: the kernel looks for a matching socket and charges packet-processing and queue work.
3. Closed-port response: policy may emit ICMP Destination Unreachable, Port Unreachable; ICMP rate limiting can bound but not erase the inbound cost.
4. Open-port pressure: a real service may parse, authenticate, allocate, log, or reply before it rejects the payload, making application work the larger cost.
5. Collateral failure: link saturation, receive drops, CPU pressure, and response traffic delay legitimate datagrams.

Do not let local ICMP suppression become the only mitigation: it reduces response work but cannot recover an already saturated ingress link. Likewise, DTLS can reject unauthenticated application data, but the receiver still spends network and cryptographic work reaching that decision. Capacity tests should include invalid packets, not only successful request throughput, and dashboards should separate link bytes, kernel drops, socket drops, authentication failures, ICMP generation, and application queue depth.

Under-the-Hood Check

Keep transport, security, and routing claims separate with the diagram Figure 3.2.

In the diagram Figure 3.2, uDP or TCP: delivery chooses datagram overhead or ordered stream state; DTLS: protect UDP supplies its security boundary; RPL: reach the root selects paths over lossy links. The Boundary rule blocks a DTLS claim from being reused as reliability evidence.

3.5 Summary

UDP is a deliberately small transport protocol. It gives applications ports, datagram boundaries, length, and checksum behavior without creating a reliable ordered stream. That makes UDP useful for bounded IoT messages, discovery traffic, and application protocols that own their own acknowledgement or retry behavior.

For review, the important evidence is the receiver contract: message meaning, freshness, duplicate handling, retry ownership, protection boundary, operational visibility, and retest triggers.

3.6 Key Takeaway

3.7 See Also