UDP(4)              Linux Programmer's Manual              UDP(4)

NAME
       udp - UDP protocol on top of IPv4.

SYNOPSIS
       #include <sys/socket.h>
       #include <netinet/in.h>
       udp_socket = socket(PF_INET, SOCK_DGRAM, 0);

DESCRIPTION
       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
       ip(4).

       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.

ADDRESS FORMAT
       UDP  uses the IPv4 sockaddr_in address format described in
       ip(4).

ERROR HANDLING
       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.

ERRORS
       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.

VERSIONS
       IP_RECVERR is a new feature in Linux 2.2

SEE ALSO
       ip(4),socket(4),raw(4)

       RFC1191 for a description of path mtu discovery.

Linux Man Page              2 Oct 1998                          1