Differences between version 4 and predecessor to the previous major change of udp(7).
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 4 | Last edited on Monday, February 10, 2003 10:16:41 pm | by PerryLorier | Revert |
| Older page: | version 2 | Last edited on Saturday, February 8, 2003 3:12:15 am | by KitPeters | Revert |
@@ -1,165 +1,73 @@
-UDP
-!!!UDP
-NAME
-SYNOPSIS
-DESCRIPTION
-ADDRESS FORMAT
-ERROR HANDLING
-IOCTLS
-ERRORS
-VERSIONS
-CREDITS
-SEE ALSO
-----
-!!NAME
-
-
udp - User Datagram Protocol for IPv4
!!SYNOPSIS
-
-
-__#include __
#include <sys/socket.h>
#include <netinet/in.h>
udp_socket = socket(PF_INET, SOCK_DGRAM, 0);
+
!!DESCRIPTION
+This is an implemention of the User Datagram Protocol described in RFC768. It implements a connectionless, unreliable 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 addresses are 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 destination address is set and datagrams can now be sent 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 can be bound to an local address first by using bind(2). Otherwise the socket layer will automatically assign a free local port out of the range defined by ''net.ipv4.ip_local_port_range'' and bind the socket to ''INADDR_ANY''.
-This
is an implemention of
the User Datagram Protocol
-described in RFC768. It implements a connectionless
,
-unreliable datagram
packet service. Packets may be reordered
-or duplicated before they arrive. UDP generates
and checks
-checksums to catch transmission errors
.
+All receive operations return only one packet. When the packet
is smaller than
the passed buffer only that much data is returned
, when it is bigger the
packet is truncated
and the __MSG_TRUNC__ flag is set. ''MSG_WAITALL'' is not supported
.
+IP options may be sent or received using the socket options described in ip(7). 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(7).
-When a UDP socket
is created, its local and remote addresses
-are 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
destination address is
-set and datagrams can now be sent 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 can be bound to an
-first by using bind(2). Otherwise the
-socket layer will automatically assign a free local port out
-of the range defined by ''net.ipv4.ip_local_port_range''
-bind
the socket
to ''INADDR_ANY''
.
+When the __MSG_DONTROUTE__ flag
is set
on sending
the destination 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] (Maximum Transmission Unit). A more network friendly alternative is to use path MTU discovery as described in the __IP_PMTU_DISCOVER__ section of ip(7).
-All receive operations return only one packet. When the
-packet is smaller than the passed buffer only that much data
-is returned, when it is bigger the packet is truncated and
-the __MSG_TRUNC__ flag is set. ''MSG_WAITALL'' is not
-supported.
-
-
-IP options may be sent or received using the socket options
-described in ip(7). 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(7).
-
-
-When the __MSG_DONTROUTE__ flag is set on sending the
-destination 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 (Maximum Transmission Unit). A more network
-friendly alternative is to use path MTU discovery as
-described in the __IP_PMTU_DISCOVER__ section of
-ip(7).
!!ADDRESS FORMAT
+UDP uses the IPv4 __sockaddr_in__ address format described in ip(7).
-
-UDP uses the IPv4 __sockaddr_in__ address format
-described in ip(7).
!!ERROR HANDLING
+All fatal errors will be passed to the user as an error return even when the socket is not connected. This includes asynchronous errors received from the network. You may get an error for an earlier packet that was sent on the same socket. This behaviour differs from many other BSD socket implementations which don't pass any errors unless the socket is connected. Linux's behaviour is mandated by RFC:1122 .
+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 __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.
-All fatal errors will be passed to
the user as an error
-return even when the socket
is not connected. This includes
-asynchronous
errors received from
the network. You may get
-an
error for an earlier packet that was sent on
the same
-socket. This behaviour differs from many other BSD socket
-implementations which don't pass any errors unless the
-socket is connected. Linux's behaviour is mandated by
-RFC1122
__.
+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
.
-
-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
-__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.
!!IOCTLS
These ioctls can be accessed using ioctl(2). The
correct syntax is:
-__int__ ''value''__;
-__''error'' __= ioctl(__''tcp_socket''__,__ ''ioctl_type''__, __''value''__);
-
+
__int__ ''value''__;
+ __''error'' __= ioctl(__''tcp_socket''__,__ ''ioctl_type''__, __''value''__);__
-__SIOCINQ__
-
-
-
-
-
+;
__SIOCINQ__:
Gets a pointer to an integer as argument. Returns the size of the next pending datagram in the integer in bytes, or 0 when no datagram is pending.
*** NOTE: 2003/07/03 SIOCINQ is undefined in Linux 2.4.20 / glibc 2.3.1 (Kit Peters) ***
-__SIOCOUTQ__
+;
__SIOCOUTQ__: Returns the number of data bytes in the local send queue. Only supported with Linux 2.4 and above.
+In addition all ioctls documented in ip(7) and socket(7) are supported.
-Returns the number of data bytes in the local send queue.
-Only supported with Linux 2.4 and above.
-
-
-In addition all ioctls documented in ip(7) and
-socket(7) are supported.
!!ERRORS
+All errors documented for socket(7) or ip(7) may be returned by a send or receive on a [UDP] socket.
-All errors documented for socket(7) or ip(7)
-may
be returned
by a send or receive on a UDP
-
+;[ECONNREFUSED]: No receiver was associated with the destination address. This might
be caused
by a previous packet sent over the
socket.
-
-__ECONNREFUSED__ No receiver was associated with the
-destination address. This might be caused by a previous
-packet sent over the socket.
!!VERSIONS
+IP_RECVERR is a new feature in Linux 2.2
-
-IP_RECVERR is a new feature in Linux 2.2
!!CREDITS
+This man page was written by Andi Kleen.
-
-This man page was written by Andi Kleen.
!!SEE ALSO
+ip(7), socket(7), raw(7), [UDP], tcp(7)
-ip(7), socket(7), raw(7)
-
-
-RFC768
for the User Datagram protocol.
-RFC1122
for the host requirements.
-RFC1191
for a description of path MTU
+RFC:768
for the User Datagram protocol. RFC:1122
for the host requirements. RFC:1191
for a description of path [
MTU]
discovery.
-----
