Summary: Socket read/write buffer

There are many discussions about the sending buffer of the socket on the Internet. Here I will summarize it and hope it will be helpful in the future. First, take a look at the following sectionCode,

// Set socket Parameters

# Define dfudprcvcachesize 256*1024 // 256 // size of the receiving buffer (in bytes)
Int optval, optlen = sizeof (INT );
Optval = dfudprcvcachesize; // you can specify the read buffer.
Err = setsockopt (isock, sol_socket, so_rcvbuf, (char *) & optval, optlen );
Optval = dfudpsndcachesize; // you can specify the read buffer.
Err = setsockopt (isock, sol_socket, so_sndbuf, (char *) & optval, optlen );

The above Code does not need to be explained. Many people should know that it is used to set the socket receiving and sending buffer under Win32. It is okay not to discuss the above Code. Since this API can be used to set the buffer, is there a limit on the maximum value of the buffer settings? Let's take a look at the discussion on this issue in major online technical forums:

"As long as the IP package is 65535 bytes, that is, 64 K

This is determined by the IP datagram structure.

The IP header has a 16-bit byte that represents the total length of the IP datagram, and its maximum value is FFFF.

Therefore, the maximum value is 65535.

This value is not purely a net data load, but contains IP header information.

The IP header is 20 bytes, And the UDP header is 8 bytes.

Therefore, part of UDP data is 65535-20-8 = 65507"

Obviously, the arguments for this comment are correct. I have also carefully reviewed the IP protocol in chapter 1 of chapter 1 of TCP/IP, we can see that the IP header indicates that the total length of the data packet is 16 bytes, and the maximum length is 65535. Of course, we need to remove the header. The argument itself is correct, but it does not prove the argument I made at the very beginning, because our argument is the maximum length set for socket sending and read buffer, obviously, this is not equal to the maximum length of an IP packet. It can be said that there is no relationship between the two. The reason is that what is the sending buffer is actually nothing more than a high concurrency period. The socket itself will maintain a buffer pool and then segment it (note: this segment is very obvious, we all know that this is the maximum length of one IP packet.) send data to the destination address. Speaking of this, I should understand a lot about it. :) unfortunately, I still did not find the maximum buffer size limit for socket reception for Win32, and in the project of the actual large concurrency communication, currently, I have set 256 kb and have not found any problems.

Since the maximum length of the IP package is mentioned, all theories should be combined with practice. In public network communication, no matter how you change the, you will eventually go through China's complex and chaotic interconnected network. In actual UDP communication, is it possible to make up one of the largest IP packets? The answer is naturally no. Aside from the MTU's largest transmission unit itself, it is usually around K, that is to say, if the data to be sent at the transport layer exceeds K, the IP layer will automatically split the data. As for how to split and group packets, UDP/tcp at the transport layer is transparent ), the problem is that the current public network router will automatically discard UDP packets larger than 1 kb (as tested). Therefore, generally, the size of the cut package we have to make is 1 K, that is, all the packages exceeding this size must be cut at the source address before being transferred out.) OK, we will summarize it today, there should be a lot of errors or omissions in it, and we will try again later.