22.1 Introduction
This chapter is a collection of various topics
that affect applications using UDP sockets. First is determining
the destination address of a UDP datagram and the interface on
which the datagram was received, because a socket bound to a UDP
port and the wildcard address can receive unicast, broadcast, and
multicast datagrams on any interface.
TCP is a byte-stream protocol and it uses a
sliding window, so there is no such thing as a record boundary or
allowing the sender to overrun the receiver with data. With UDP,
however, each input operation corresponds to a UDP datagram (a
record), so a problem arises of what happens when the received
datagram is larger than the application's input buffer.
UDP is unreliable but there are applications
where it makes sense to use UDP instead of TCP. We will discuss the
factors affecting when UDP can be used instead of TCP. In these UDP
applications, we must include some features to make up for UDP's
unreliability: a timeout and retransmission, to handle lost
datagrams, and sequence numbers, to match the replies to the
requests. We develop a set of functions that we can call from our
UDP applications to handle these details.
If the implementation does not support the
IP_RECVDSTADDR socket option, then one way to determine
the destination IP address of a UDP datagram is to bind all the
interface addresses and use select.
Most UDP servers are iterative, but there are
applications that exchange multiple UDP datagrams between the
client and server requiring some form of concurrency. TFTP is the
common example, and we will discuss how this is done, both with and
without inetd.
The final topic is the per-packet information
that can be specified as ancillary data for an IPv6 datagram: the
source IP address, the sending interface, the outgoing hop limit,
and the next-hop address. Similar information can be returned with
an IPv6 datagram: the destination IP address, received interface,
and received hop limit.
|
