How large a UDP packet is sent at a time.

Source: Internet
Author: User

When it comes to UDP programming, the easiest thing to think about is how many bytes are sent at a time?
Of course, this does not have the only answer, compared to different systems, different requirements, the answer is not the same, here just like the ICQ type of sending chat messages to analyze, for other cases, may also get a little help:
First of all, we know that tcp/ IP is generally considered to be a four-layer protocol system, including link layer, network layer, Transport layer, application layer. UDP belongs to transport layer, below we from down to previous step by step: the length of the
Ethernet (Ethernet) data frame must be between 46-1500 bytes, which is determined by the physical characteristics of the Ethernet. This 1500 byte is called the MTU of the link layer (the Maximum transmission unit). This does not mean that the length of the link layer is limited to 1500 bytes, but this MTU refers to the data area of the link layer. Does not include the link layer header and the trailing 18 bytes. So, in fact, this 1500 byte is the length limit of the network layer IP datagram. Because the header of the IP datagram is 20 bytes, Therefore, the data of the IP datagram has a maximum of 1480 bytes. And this 1480 byte is used to put TCP packets or UDP transmitted UDP datagram. And because the first 8 bytes of the UDP datagram, Therefore, the maximum data area length for a UDP datagram is 1472 bytes. This 1472 byte is the number of bytes we can use. :)
What happens when we send more UDP data than 1472? This means that the IP datagram is larger than 1500 bytes, which is greater than the MTU. This time the sender IP layer needs to be fragmented (fragmentation). Divide the datagram into pieces so that each piece is smaller than the MTU. The receiver IP layer needs to be reorganized for the datagram. So there's a lot more to be done, What's more, because of the characteristics of UDP, when a piece of data transmission is lost, the reception is not able to reorganize the datagram. Causes the entire UDP datagram to be discarded.
Therefore, in a normal LAN environment, I recommend that you control UDP data below 1472 bytes as well.
programming on the Internet is different because routers on the Internet may set the MTU to a different value. If we assume that the MTU is sending data to 1500来, and that the MTU value of a network passing through is less than 1500 bytes, Then the system will use a series of mechanisms to adjust the MTU value, so that the datagram can reach the destination smoothly, so there are many unnecessary operations. Given that the standard MTU value on the Internet is 576 bytes, So I recommend that you do UDP programming on the Internet. It is best to have UDP data-length controls within 548 bytes (576-8-20).

In theory, the maximum length of an IP datagram is 65535 bytes, which is limited by the IP header 16-bit total Length field. Remove the 20-byte IP header and the 8-byte UDP header, and the maximum length of user data in the UDP datagram is 65507 bytes. However, most implementations provide a smaller length than this maximum value.
We will encounter two limiting factors. First, the application may be limited by its program interface. The socket API provides a function that the application can call to set the length of the receive and send caches. For UDP sockets, this length is directly related to the length of the maximum UDP datagram that the application can read and write. Most systems now default to read and write UDP datagrams that are larger than 8192 bytes (using this default value because 8192 is the default for NFS read and write user data).
The second limitation is the kernel implementation from TCP/IP. There may be some implementation features (or errors) that make the IP datagram length less than 65535 bytes.
The maximum IP datagram length using the loopback interface under SunOS 4.1.3 is 32767 bytes. A value larger than it will go wrong.
However, from bsd/386 to SunOS 4.1.3, Sun can receive a maximum IP datagram length of 32786 bytes (that is, 32758 bytes of user data).
With the loopback interface under Solaris 2.2, the maximum IP datagram length is 65535 bytes.
The maximum IP datagram length that is sent from Solaris 2.2 to Aix 3.2.2 can be 65535 bytes. Obviously, this limitation is related to the implementation of the source and destination ends.
The host must be able to receive an IP datagram with a minimum of 576 bytes. In the design of many UDP applications, the application data is limited to 512 bytes or less, so it is less than this limit value.
Because IP can send or receive datagrams of a specific length does not mean that the receiving application can read data of that length. Therefore, the UDP programming interface allows the application to specify the maximum number of bytes to return each time. What happens if the received datagram is longer than the length the application can handle? Unfortunately, the answer to this question depends on the programming interface and implementation.
A typical version of the Berkeley socket API truncates datagrams and discards any excess data. When the application knows, it is related to the version (4.3BSD Reno and later versions can notify the application that the datagram is truncated).
The socket API under SVR4 (including Solaris 2.x) does not truncate datagrams. The partial data is returned in subsequent reads. It also does not notify the application to read from a single UDP datagram multiple times. The TLI API does not discard data. Instead, it returns a flag indicating that more data can be obtained, and the subsequent read of the application returns the remainder of the datagram. When we discuss TCP, we find that it provides a continuous stream of bytes to the application without any information boundaries. TCP transmits data at the length required by the application read operation, so there is no data loss under this interface.

http://blog.csdn.net/adcxf/article/details/3961775

How large a UDP packet is sent at a time.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.