UDP socket programming has a different shape from TCP. A server creates one datagram socket, binds it to a local address, and receives messages from many clients through that same socket. There is no listening state, no accept() call, and no separate connected socket for each peer.

The simpler lifecycle comes with a smaller transport contract. UDP preserves the boundary of each delivered datagram, but it does not guarantee that a datagram arrives, arrives once, or arrives in order. Applications must decide whether loss matters and, if it does, what response matching, timeouts, retries, and duplicate handling are appropriate.

This chapter builds a small UDP echo service in Python and Java using only their standard libraries. The client sends one request datagram containing a request ID and UTF-8 payload. The server sends the same ID and payload back in a response datagram.

The example demonstrates the essential UDP programming concerns:

The server processes datagrams sequentially. One socket can communicate with many clients even though the program uses no threads.

A typical UDP server performs four core operations:

A client can let the operating system choose its local address and port:

The server's receive operation returns two pieces of information:

The sender address is essential because an unconnected UDP socket can receive from many peers. The server uses that address as the destination of its reply.

Unlike TCP, UDP does not create an accepted socket for client A or client B. After replying, the server calls receive again on the same bound socket.

Each UDP send operation creates one datagram. If a client performs:

the receiver never gets one merged "ALPHABETA" datagram. If both arrive, it receives two separate datagrams.

UDP can still lose, reorder, or duplicate them:

This message-oriented behavior means the example does not need a length prefix to find the end of a request. The receive call returns at most one datagram.

The receiving buffer still matters. If a datagram is larger than the supplied buffer, the excess is normally discarded. A later receive does not return the missing tail. Applications need a maximum datagram size and a buffer large enough to detect or accept it.

The example uses a small binary header followed by a payload:

The fields are:

The complete application datagram is limited to 1,200 bytes. With a six-byte header, the maximum payload is 1,194 bytes.

The 1,200-byte limit is a conservative teaching choice that avoids large datagrams on ordinary networks. It is not a universal promise that fragmentation can never occur: tunnels, unusual links, and path configuration can reduce the usable size.

For a request ID of 0x10203040 and the payload Hi, the datagram contains:

The request ID lets the client distinguish the expected response from an old, duplicated, or unrelated datagram. It provides correlation, not reliability or duplicate prevention.

Python's struct module can encode the protocol header:

The format string "!BBI" means:

HEADER.size is 6. UDP already supplies the total datagram length, so the protocol does not include a separate payload-length field.

Save the following program as udp_server.py:

Creating the server socket uses:

AF_INET selects IPv4, while SOCK_DGRAM selects UDP's datagram interface. Creating the socket does not contact any peer.

The server binds to:

The loopback address keeps the demonstration local to the machine. The operating system delivers matching UDP datagrams to this bound socket.

The central operation is:

recvfrom() returns one datagram and its sender address. The buffer is one byte larger than the application's maximum. If the returned data exceeds 1,200 bytes, the server knows the sender violated its size limit and discards the datagram.

The reply uses the address returned by recvfrom():

The server does not remember a client connection. Each request contains the information needed to process and reply to that datagram.

The client waits up to one second for each attempt and sends the same request at most three times. It ignores datagrams that come from a different address or contain a different request ID.

Save this program as udp_client.py:

secrets.randbits(32) generates the request ID. Randomness does not prove uniqueness, but a 32-bit value is sufficient to correlate one small teaching client's outstanding request.

The first sendto() implicitly assigns the client an ephemeral local UDP port. The same socket is retained for all attempts, so retransmissions use the same local endpoint and request ID.

The response loop uses a deadline rather than applying a fresh one-second wait to every unexpected datagram. Traffic from an unrelated sender therefore cannot extend the attempt indefinitely.

The client validates both:

Receiving any UDP datagram is not enough. An unconnected UDP socket can receive from more than one source, and an old response may arrive after the client has moved on to another request.

Start the server in one terminal:

It prints:

Run the client from another terminal:

The client output is similar to:

The server reports:

Run several clients. Their datagrams all arrive through the same server socket, while the sender addresses contain different ephemeral client ports.

If the client runs while the server is stopped, it normally sends successfully and then times out three times. UDP has no connection-establishment step that immediately proves a server is listening.

Java uses DatagramSocket for UDP communication and DatagramPacket as the container passed to send and receive operations.

The protocol header can be encoded with ByteBuffer:

Java's int is signed, but putInt() writes its 32 bits unchanged. The Python implementation interprets the same bits as an unsigned value from 0 through 4,294,967,295. Equality still works because the Java client and server preserve the same bit pattern.

Decoding must respect the received packet's offset and length:

DatagramPacket can refer to a region within an array, so decoding the entire backing array would be incorrect. The slice() call creates a view limited to the received region.

Save the following program as UdpServer.java:

new DatagramSocket(null) creates an unbound socket object. Calling bind() then gives it the explicit loopback endpoint 127.0.0.1:5001.

The server reuses one 1,201-byte receive array. Each DatagramPacket is reset to the full array capacity before receive() runs. The decoder copies the payload out before the next datagram overwrites the buffer.

receive() blocks until a datagram arrives or an I/O error occurs. It does not accept a connection and does not create another socket.

The incoming packet retains the sender's SocketAddress, which the outgoing packet uses as its destination:

The Java client uses the same one-second deadline and three-attempt limit as the Python client.

Save this program as UdpClient.java:

new DatagramSocket() immediately binds the client to an available local UDP port. The first send does not establish a transport connection.

setSoTimeout() bounds each blocking receive(). The code recalculates the remaining time before every receive so ignored traffic cannot restart the full response deadline.

The same request bytes and request ID are used for every attempt. A delayed response from an earlier attempt can therefore satisfy a later attempt without being mistaken for a different operation.

Compile both files:

Start the server:

Run the client in another terminal:

The client output is similar to:

Java stores the request ID in a signed int, but Integer.toUnsignedString() prints the corresponding unsigned 32-bit value used on the wire.

Both implementations use the same datagram format:

Either client can therefore use either server:

Start UdpServer and run udp_client.py, or start udp_server.py and run UdpClient. The operating systems and languages exchange datagram bytes; they do not exchange Python tuples or Java objects.

Interoperability depends on agreement about:

UDP preserves each datagram boundary, but it does not interpret the bytes inside that boundary.

The examples use unconnected UDP sockets. Every send names a destination, and every receive reports a sender:

This model is natural for a server that communicates with many peers.

An application can also call connect() on a UDP socket:

For UDP, connect() normally records a default peer in the local operating system. It does not perform a TCP-style handshake, create a reliable stream, or prove that an application is listening at the destination.

A connected UDP socket provides three conveniences:

The server remains connectionless at the transport level. "Connected UDP" is a socket API mode, not a change to UDP's delivery guarantees.

TCP uses an empty receive result to signal end-of-stream. UDP has no stream and no equivalent end-of-stream marker.

A UDP sender can transmit a zero-byte datagram. If it arrives:

In Java, DatagramPacket.getLength() can be 0 for a received empty datagram.

The echo protocol rejects such a datagram because it is shorter than the required six-byte header. That is an application-protocol decision, not a UDP restriction.

Closing one UDP socket also does not send a general end-of-conversation signal to its peers. If an application needs session state or a goodbye message, it must define those concepts in its own protocol.

A receive operation needs an application buffer before it knows how large the next datagram will be.

Suppose the sender transmits a 2,000-byte datagram while the receiver provides a 1,200-byte buffer. The receiver may get the first 1,200 bytes, while the remaining 800 bytes are discarded. The next receive waits for a new datagram; it does not continue the old one.

Some socket APIs can expose a truncation flag, but the basic Python recvfrom() and Java DatagramPacket interfaces used here do not provide the original length after truncation.

The example allocates 1,201 bytes while accepting at most 1,200. A datagram larger than the protocol maximum fills at least the extra byte, allowing the program to reject the received data instead of interpreting a permitted-length prefix of an oversized message.

This technique enforces the application's limit. It does not reconstruct a truncated datagram.

UDP treats one send as one datagram, but IP still has to carry that datagram across a path with finite packet sizes.

If a datagram is too large for the path, several things can happen depending on IP version, operating-system settings, and network behavior:

If any required fragment is lost, the receiving host cannot reconstruct the original UDP datagram. The entire datagram is then unavailable to the application.

Small application datagrams reduce this risk. A protocol that transfers large objects should normally split data into deliberately sized application messages and define ordering, loss recovery, and reassembly limits rather than relying on large fragmented UDP datagrams.

There is no single payload size that is optimal for every environment. Encapsulation through VPNs or tunnels consumes additional bytes, and an Internet path can differ from a local test network.

When the UDP client times out, it cannot tell which event occurred:

Retrying can recover from temporary loss. It can also cause the server to process the same logical request more than once.

The request ID lets a stateful server recognize that both datagrams represent the same logical request, but the echo server does not store IDs. Echoing is safe to repeat because it has no side effect.

For an operation such as charging a card, decrementing inventory, or creating a record, a retry policy needs an application-level idempotency design. The server might store the outcome associated with a request ID and return the stored result when the request is repeated.

Retries should be bounded. Repeatedly sending at a fixed high rate during an outage increases congestion and server load. Production protocols commonly add increasing delays and random jitter between attempts.

UDP itself does not provide congestion control for application traffic. A sender must avoid transmitting sustained traffic faster than the network and receiver can handle.

For a normal UDP socket, a successful send means the local operating system accepted one datagram for transmission.

It does not prove that:

When no server is listening, an unconnected UDP send can still succeed. The network might later return an ICMP error, but whether and when that error reaches the application depends on the operating system, socket mode, network path, and firewall behavior.

The portable application strategy is to define the response it expects and enforce a deadline. Silence is not a detailed diagnosis; it only means the expected response did not arrive in time.

The client sends successfully but always times out. The server may be stopped, bound to another address, using another port, blocked by a firewall, or returning a response to the wrong sender address.

The server logs a request but the client times out. The response may be lost, delayed, filtered, or sent to a client port that is no longer open.

The server processes one operation twice. The original response may have been lost, causing the client to retry. A request ID without server-side deduplication does not prevent repeated work.

The client accepts the wrong response. It may not be checking the sender address, message type, or request ID.

The payload is corrupted at the application level. The peers may disagree about header layout, byte order, or text encoding even though UDP delivered the datagram bytes intact.

Large messages fail while small messages work. Large datagrams may exceed an application buffer, a local send limit, or a usable path size.

Some datagrams disappear under load. The receiver may not drain its socket quickly enough, causing its kernel receive buffer to overflow. UDP does not apply TCP-style backpressure to make the sender wait for that receiver.

Responses arrive out of order. Several requests may be in flight, or an older response may have been delayed. Correlate responses by request ID rather than arrival position.

Calling listen() or accept() on a UDP socket. UDP servers bind one datagram socket and receive messages directly.

Creating one server socket per client. A normal UDP server uses the sender address returned with each datagram to reply through the same bound socket.

Ignoring the sender address. An unconnected socket can receive from several peers. Validate the source when a client expects one specific server.

Treating b"" as connection closure. In UDP it represents a valid empty datagram, not end-of-stream.

Assuming a receive buffer can collect the rest later. If a datagram is truncated, the discarded tail is not returned by another receive.

Sending very large datagrams casually. Fragmentation and path-size differences make large datagrams fragile.

Waiting forever for a response. UDP provides no delivery guarantee. Clients need explicit deadlines.

Retrying non-idempotent work blindly. A lost response can cause the same request to be processed again.

Generating a new request ID for every retry. Retransmissions of one logical operation should keep the same ID so the receiver can correlate or deduplicate them.

Assuming UDP connect() proves reachability. It records a peer locally but does not perform a transport handshake.

Treating send success as delivery. It normally means only that the local networking stack accepted the datagram.

Sending without rate control. UDP does not automatically slow an application to protect the receiver or shared network.

A UDP server binds one datagram socket and uses it to receive from and reply to many sender addresses. Each successful receive returns at most one complete datagram, and separate sends are never merged. UDP guarantees neither delivery, order, nor duplicate suppression.

Request IDs correlate responses and retries but prevent repeated work only when the server deduplicates them. Receive buffers must fit allowed datagrams because truncated bytes cannot be recovered. Smaller datagrams reduce fragmentation risk, though no size fits every path. Deadlines and bounded retries turn silence into controlled failure.

Connected UDP simplifies peer selection without adding a handshake or reliability. Python and Java interoperate when their datagram header, byte order, and payload encoding match.

Treat each datagram as an independent, potentially lost or duplicated message, adding only the reliability the application needs.