NAME

udp − Internet User Datagram Protocol

SYNOPSIS

None; comes automatically with inet(4F).

DESCRIPTION

The User Datagram Protocol (UDP) is defined to make available a datagram mode of packet switched computer communicaton in the environment of an interconnected set of computer networks.  The protocol assumes that the Internet Protocol (IP) as described in ip(4P) is used as the underlying protocol.

The protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism.  The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed.  Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP) as described in tcp(4P).

The UNIX system implementation of UDP makes it available as a socket of type SOCK_DGRAM.  UDP sockets are normally used in a connectionless fashion, with the sendto and recvfrom calls described in send(2) and recv(2).

A UDP socket is created with a socket(2) call:

s = socket(AF_INET, SOCK_DGRAM, 0);

The socket initially has no address associated with it, and may be given an address with a bind(2) call as described in inet(4F). If no bind call is done, then the address assignment procedure described in inet(4F) is repeated as each datagram is sent.

When datagrams are sent the system encapsulates the user supplied data with UDP and IP headers.  Unless the invoker is the super-user datagrams which would become broadcast packets on the network to which they are addressed are not allowed.  Unless the socket has had a SO_DONTROUTE option enabled (see socket(2)) the outgoing datagram is routed through the routing tables as described in routing(4N). If there is insufficient system buffer space to temporarily hold the datagram while it is being trasmitted, the sendto may result in a ENOBUFS error.  Other errors (ENETUNREACH, EADDRNOTAVAIL, EACCES, EMSGSIZE) may be generated by icmp(4P) or by the network interfaces themselves, and are reflected back in the send call. 

As each UDP datagram arrives at a host the system strips out the IP options and checksums the data field, discarding the datagram if the checksum indicates that the datagram has been damaged.  If no socket exists for the datagram to be sent to then an ICMP error is returned to the originating socket.  If a socket exists for this datagram to be sent to, then we will append the datagram and the address from which it came to a queue associated with the datagram socket.  This queue has limited capacity (2048 bytes of datagrams) and arriving datagrams which will not fit within its high-water capacity are silently discarded. 

UDP processes ICMP errors reflected to it by icmp(4P). QUENCH errors are ignored (this is well considered a bug); UNREACH, TIMXCEED and PARAMPROB errors cause the socket to be disconnected from its peer if it was bound to a peer using bind(2) so that subsequent attempts to send datagrams via that socket will give an error indication.

The UDP datagram protocol differs from IP datagrams in that it adds a checksum over the data bytes and contains a 16-bit socket address on each machine rather than just the 32-bit machine address; UDP datagrams are addressed to sockets; IP packets are addressed to hosts. 

SEE ALSO

recv(2), send(2), inet(4F)
“User Datagram Protocol”, RFC768, John Postel, USC-ISI (Sun 800-1054-01)

BUGS

SIOCSHIWAT and SIOCGHIWAT ioctl’s to set and get the high water mark for the socket queue, and so that it can be changed from 2048 bytes to be larger or smaller, have been defined (in <sys/ioctl.h>) but not implemented. 

Something sensible should be done with QUENCH errors if the socket is bound to a peer socket. 

Sun Release 3.0β  —  Last change: 26 July 1985