Basic Concepts, Protocols and Terminology - An Introduction to Network Programming with Java - page 7

At the receiving end, the message travels up through the layers until it reaches
the receiving application layer. As it does so, each layer converts the message into a
form suitable for receipt by the next layer (effectively reversing the corresponding
process carried out at the sending end) and carries out checks appropriate to its own
protocol. If recalculation of checksums reveals that some of the data has been cor-
rupted or checking of sequence numbers shows that some data has not been received,
then the transport layer requests re-transmission of the corrupt/missing data.
Otherwise, the transport layer acknowledges receipt of the packets. All of this is
completely transparent to the application layer. Once all the data has been received,
converted and correctly sequenced, it is presented to the recipient application layer
as though that layer had been in direct communication with the sending application
layer. The latter may then send a response in exactly the same manner (and so on).
In fact, since TCP provides full duplex transmission, the two ends of the connection
may be sending data simultaneously.
The above description has deliberately hidden many of the low-level details of
implementation, particularly the tasks carried out by the host-to-network layer.
In addition, of course, the initial transmission may have passed through several
routers and their associated layers before arriving at its ultimate destination.
However, this high-level view covers the basic stages that are involved and is quite
suffi cient for our purposes.
Another network model that is often referred to is the seven-layer Open Systems
Interconnection (OSI) model. However, this model is an unnecessarily complex one
for our purposes and is better suited to non-TCP/IP networks anyway.

1.6 UDP

Most Internet applications use TCP as their transport mechanism. In contrast to
TCP, User Datagram Protocol (UDP) is an unreliable protocol, since:

(i) it doesn't guarantee that each packet of data will arrive;
(ii) it doesn't guarantee that packets will be in the right order.

UDP doesn't re-send a packet if it fails to arrive or there is some other error and it
doesn't re-assemble packets into the correct sequence at the receiving end. However,
the TCP overhead of providing facilities such as confirmation of receipt and
re-transmission of lost or corrupted packets used to mean that UDP was signifi -
cantly faster than TCP. For many applications (e.g., fi le transfer), this didn't really
matter greatly. As far as these applications were concerned, it was much more
important that the data arrived intact and in the correct sequence, both of which
were guaranteed by TCP. For some applications, however, the relatively slow
throughput speed offered by TCP was simply not feasible. Such applications
included the streaming of audio and video fi les (i.e., the playing of those fi les while
they were being downloaded). Such applications didn't use TCP, because of its large
overhead. Instead, they used UDP, since their major objective was to keep playing