Java Reference
In-Depth Information
errors
.
log
(
Level
.
SEVERE
,
ex
.
getMessage
(),
ex
);
}
}
}
catch
(
IOException
ex
)
{
errors
.
log
(
Level
.
SEVERE
,
ex
.
getMessage
(),
ex
);
}
}
}
As you can see in this example, UDP servers tend not to be as multithreaded as TCP
servers. They usually don't do a lot of work for any one client, and they can't get blocked
waiting for the other end to respond because UDP never reports errors. Unless a lot of
time-consuming work is required to prepare the response, an iterative approach works
just fine for UDP servers.
The DatagramPacket Class
UDP datagrams add very little to the IP datagrams they sit on top of.
Figure 12-1
shows
a typical UDP datagram. The UDP header adds only eight bytes to the IP header. The
UDP header includes source and destination port numbers, the length of everything
that follows the IP header, and an optional checksum. Because port numbers are given
as two-byte unsigned integers, 65,536 different possible UDP ports are available per
host. These are distinct from the 65,536 different TCP ports per host. Because the length
is also a two-byte unsigned integer, the number of bytes in a datagram is limited to
65,536 minus the eight bytes for the header. However, this is redundant with the data‐
gram length field of the IP header, which limits datagrams to between 65,467 and 65,507
bytes. (The exact number depends on the size of the IP header.) The checksum field is
optional and not used in or accessible from application layer programs. If the checksum
for the data fails, the native network software silently discards the datagram; neither the
sender nor the receiver is notified. UDP is an unreliable protocol, after all.
