Unix Network Programming Manual
Datagram Services (UDP)
The previous portions of this manual have dealt with stream services. These
services have certain characteristics that may or may not be what you want
to use in a particular situation. A comparison of stream services and
datagram services (the other typical Unix service) are:
| Service
| Stream
| Datagram
|
| Format
| Byte oriented
| Message oriented
|
| Reliability
| Complete
| Minimal
|
| Model
| Connection-oriented
| Connectionless
|
| I/O Mechanism
| send/recv
| sendto/recvfrom
|
So there are four things that we to discuss relative to the two formats.
Format
Stream services view the collection of data sent from one end to the other
as a continuous flow of bytes, regardless of how it is sent. Using TCP for
example, you might send 10 bytes at a time, but TCP reserves the right to
package the data and send it in whatever packet sizes it finds efficient.
The result is that you have to explicitly maintain your own boundaries
in your protocols. Datagram services, such as UDP send the messages just
as they are delivered. If you send data 10 bytes at a time using datagrams,
they are delivered 10 bytes at a time to the receiver.
Reliability
The stream services for TCP is a reliable protocol. It guarantees that the
data is arriving in the correct order and that no packets have been lost.
Also to the best of its ability, it guarantees that the data has not been
corrupted. Datagram services such as UDP offer none of these measures,
except a rudimentaty test for corruption. Therefore, if you use datagrams,
you will have to perform the necessary error testing. In some cases, none
is needed, in other, some or all of the TCP measures may be required.
The trade-off is that protocols like UDP have less overhead and may provide
better performance.
Model
The Unix stream services provide specific support for the connection-oriented
client-server model, with calls like accept and connect.
The datagram services provide nothing except functions to send and receive
data. Using these services you can establish connectionless peer-to-peer
relationships, where either side can go first, or you can create client-server
relationships where you create messages that function as connect and accept.
However, the protocols themselves are connectionless and each message is
delivered as though it is the only one that has been passed between the
endpoints.
I/O Mechanism
You have seen the send and recv calls that are used by stream services. The
datagram use slightly different methods as shown below:
int sendto (int sock, char *message, int length, int flags,
struct sockaddr *addr, int addrlen)
int recvfrom (int sock, char *message, int length, int flags,
struct sockaddr *addr, int *addrlen)
These are similar to send and recv, except that an address is included in
each. The address is required because there is no continuing connection
between the endpoints. Each message sent must contain the address of the
process that is to receive it. Similarly, if a message is received, it
can only be replied to if the receiver explicitly captures the senders
address for later use. When a process sends a message, the operating
explicitly assigns a port number so that a response may be sent, but the
port is not permanently assigned to the process, as in the bind call. If
a process expects to get unsolicited messages, it must bind its socket
to a specific address (host-port pair).
An example of a datagram-based network communication application is in
on the next page.
