The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Интерактивная система просмотра системных руководств (man-ов)

 [Cписок руководств | Печать]

udp (4)
  • udp (4) ( FreeBSD man: Специальные файлы /dev/* )
  • >> udp (4) ( Linux man: Специальные файлы /dev/* )
  • udp (7) ( Solaris man: Макропакеты и соглашения )
  • udp (7) ( Русские man: Макропакеты и соглашения )
  • udp (7) ( Linux man: Макропакеты и соглашения )
  • Ключ udp обнаружен в базе ключевых слов.


    udp - UDP protocol on top of IPv4.


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



    This is an implemention of the User Data 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 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 truncated 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 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. 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 sockets with many destinations the discovered MTU per destination can be accessed using the error queue after a pmtudisc 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 temporary socket to the destination address and retrieve the MTU using the IP_MTU getsockopt.



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



    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 implementations 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 destination 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.




    Поиск по тексту MAN-ов: 

    Inferno Solutions
    Hosting by

    Закладки на сайте
    Проследить за страницей
    Created 1996-2023 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру