Java Network Programming (3rd ed) [Electronic resources] نسخه متنی

13.1 The UDP Protocol

The obvious question to ask is why
anyone would ever use an unreliable protocol. Surely, if you have
data worth sending, you care about whether the data arrives
correctly? Clearly, UDP isn't a good match for
applications like FTP that require reliable transmission of data over
potentially unreliable networks. However, there are many kinds of
applications in which raw speed is more important than getting every
bit right. For example, in real-time audio or video, lost or swapped
packets of data simply appear as static. Static is tolerable, but
awkward pauses in the audio stream, when TCP requests a
retransmission or waits for a wayward packet to arrive, are
unacceptable. In other applications, reliability tests can be
implemented in the application layer. For example, if a client sends
a short UDP request to a server, it may assume that the packet is
lost if no response is returned within an established period of time;
this is one way the Domain Name System (DNS) works. (DNS can
also operate over TCP.) In fact, you could implement a reliable file
transfer protocol using UDP, and many people have:
Network File System (NFS), Trivial FTP
(TFTP), and FSP, a more distant relative of FTP, all use UDP. (The
latest version of NFS can use either UDP or TCP.) In these protocols,
the application is responsible for reliability; UDP
doesn't take care of it. That is, the application
must handle missing or out-of-order packets. This is a lot of work,
but there's no reason it can't be
donealthough if you find yourself writing this code, think
carefully about whether you might be better off with TCP.

The difference between TCP and UDP is often
explained by analogy with the phone system and the post office. TCP
is like the phone system. When you dial a number, the phone is
answered and a connection is established between the two parties. As
you talk, you know that the other party hears your words in the order
in which you say them. If the phone is busy or no one answers, you
find out right away. UDP, by contrast, is like the postal system. You
send packets of mail to an address. Most of the letters arrive, but
some may be lost on the way. The letters probably arrive in the order
in which you sent them, but that's not guaranteed.
The farther away you are from your recipient, the more likely it is
that mail will be lost on the way or arrive out of order. If this is
a problem, you can write sequential numbers on the envelopes, then
ask the recipients to arrange them in the correct order and send you
mail telling you which letters arrived so that you can resend any
that didn't get there the first time. However, you
and your correspondent need to agree on this protocol in advance. The
post office will not do it for you.

Both the phone system and the post office have their uses. Although
either one could be used for almost any communication, in some cases
one is definitely superior to the other. The same is true of UDP and
TCP. The last several chapters have all focused on TCP applications,
which are more common than UDP applications. However, UDP also has
its place; in this chapter, we'll look at what you
can do with UDP in Java. If you want to go further, look at Chapter 14.
Multicasting relies on
UDP; a multicast socket is a fairly simple
variation on a UDP socket.

Java's implementation of UDP is split into two
classes: DatagramPacket and
DatagramSocket. The
DatagramPacket class stuffs bytes of data into UDP
packets called
datagrams
and lets you unstuff datagrams that you receive. A
DatagramSocket sends as well as receives UDP
datagrams. To send data, you put the data in a
DatagramPacket and send the packet using a
DatagramSocket. To receive data, you receive a
DatagramPacket object from a
DatagramSocket and then read the contents of the
packet. The sockets themselves are very simple creatures. In UDP,
everything about a datagram, including the address to which it is
directed, is included in the packet itself; the socket only needs to
know the local port on which to listen or send.

This division of labor contrasts with the Socket
and ServerSocket classes used by TCP. First, UDP
doesn't have any notion of a unique connection
between two hosts. One socket sends and receives all data directed to
or from a port without any concern for whom the remote host is. A
single DatagramSocket can send data to and receive
data from many independent hosts. The socket isn't
dedicated to a single connection, as it is in TCP. In fact, UDP
doesn't have any concept of a connection between two
hosts; it only knows about individual datagrams. Figuring out who
sent what data is the application's responsibility.
Second, TCP sockets treat a network connection as a stream: you send
and receive da