Network Clients - Java - page 519

sary relation to any other. [ 41 ] A common analogy is that TCP is like talking on the telephone,
whereas UDP is like sending postcards or maybe fax messages.
The differences show up most in error handling. Packets can, like postcards, go astray. When
was the last time the postman rang your bell to tell you that the post office had lost one of
several postcards it was supposed to deliver to you? That's not going to happen, because the
post office doesn't keep track of postcards. On the other hand, when you're talking on the
phone and there's a noise burst—like somebody yelling in the room, or even a bad connec-
tion—you notice the failure in real time, and you can ask the person at the other end to repeat
what they just said.
With a stream-based connection like a TCP socket, the network transport layer handles errors
for you: it asks the other end to retransmit. With a datagram transport such as UDP, you have
to handle retransmission yourself. It's kind of like numbering the postcards you send so that
you can go back and resend any that don't arrive—a good excuse to return to your vacation
spot, perhaps.
Another difference is that datagram transmission preserves message boundaries. That is, if
you write 20 bytes and then write 10 bytes when using TCP, the program reading from the
other end will not know if you wrote one chunk of 30 bytes, two chunks of 15, or even 30 in-
dividual characters. With a DatagramSocket , you construct a DatagramPacket object for
each buffer, and its contents are sent as a single entity over the network; its contents will not
be mixed together with the contents of any other buffer. The DatagramPacket object has
methods like getLength() , setPort() , and so on.