UDP(4) Linux Programmer's Manual UDP(4)
udp - UDP protocol on top of IPv4.
udp_socket = socket(PF_INET, SOCK_DGRAM, 0);
This is an implemention of the User Data Protocol
described in RFC768. It implements a connectionless, unre-
liable datagram packet service. Packets may be reordered
or duplicated before they arrive. UDP generates and checks
checksums to catch transmission errors.
When a UDP socket is created its local and remote address
is unspecified. Datagrams can be sent immediately using
sendto(2) or sendmsg(2) with a valid destination address
as an argument. When connect(2) is called on the socket
the default foreign address is set and datagrams can be
sent now using send(2) or write(2) without specifying an
destination address. It is still possible to send to
other destinations by passing an address to sendto(2) or
sendmsg(2). In order to receive packets the socket should
be bound to an local address first by using bind(2) , when
this is not the case the sockets layer will automatically
assign a local port on the first user receive request.
All receive operations only return one packet. When the
packet is smaller than the passed buffer only that much
data is returned, when it is bigger the packet is trun-
cated and the MSG_TRUNC flag is set.
IP options may be sent or received using the socket
options described in ip(4). They are only processed by
the kernel when the appropriate sysctl is enabled (but
still passed to the user even when it is turned off). See
When the MSG_DONTROUTE flag is set on sending the destina-
tion address must refer to an local interface address and
the packet is only sent to that interface.
UDP fragments a packet when its total length exceeds the
interface mtu. A better more polite alternative is to use
path MTU discovery and send data in right sized chunks so
that no fragmentation occurs. Linux 2.2 automatically
keeps track off the path MTU of a specific destination
when the IP_PMTU_DISCOVER socket option is set to
IP_PMTUDISC_DO. UDP will return an EMSGSIZE error then
when the datagram length exceeds the path MTU and save the
new pmtu in the error queue if enabled (this is a path mtu
recovery event). To bootstrap the pmtu discovery on
unconnected sockets it is possible to start with a big
datagram size of 65536 and let it shrink by pmtu discovery
events. When the socket is connected to a specific peer
with connect(2) the path mtu can be retrieved conveniently
using the IP_MTU socket option.t For connectionless sock-
ets with many destinations the discovered MTU per destina-
tion can be accessed using the error queue after a pmtud-
isc recovery event occurred (see ip(4) for an description
of the error queue). The application shall lower its
packet sizes then to the new path MTU. To get an initial
estimate of the PMTU it is possible to connect an tempo-
rary socket to the destination address and retrieve the
MTU using the IP_MTU getsockopt.
UDP uses the IPv4 sockaddr_in address format described in
All fatal errors will be passed to the user as an error
return even when the socket is not connected. This
behaviour differs from many other BSD socket implementa-
tions which don't pass any errors unless the socket is
connected. Linux's behaviour is mandated by RFC1122.
For compatibility with legacy code it is possible to set
the SO_BSDCOMPAT SOL_SOCKET option to receive remote
errors only when the socket has been connected (except for
for EPROTO and EMSGSIZE). It is better to fix the code to
handle errors properly than to enable this option.
Locally generated errors are always passed.
When the IP_RECVERR option is enabled all errors are
stored in the socket error queue and can be received by
recvmsg(2) with the MSG_ERRQUEUE flag set.
All errors documented for socket(4) or ip(4) may be
returned by a send or receive on a UDP socket.
ECONNREFUSED No receiver was associated with the destina-
tion address. This might be caused by a previous packet
sent over the socket.
IP_RECVERR is a new feature in Linux 2.2
RFC1191 for a description of path mtu discovery.
Linux Man Page 2 Oct 1998 1