Shulou(Shulou.com)06/03 Report--

What is the research of send function in TCP? in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Just because the tcp protocol itself is reliable does not mean that applications sending data with tcp are necessarily reliable. Whether blocked or not, the size of the send does not represent how much data the peer recv to.

In blocking mode, the process of the send function is to copy the data requested by the application to the sending cache, send it and confirm it, and then return. However, due to the existence of the sending cache, it is shown that if the size of the sending cache is larger than the size of the request, the send function returns immediately and sends data to the network at the same time; otherwise, send sends the part of data that cannot be contained in the cache to the network and waits for the peer to confirm before returning (as long as the receiver receives the data in the receiving cache, it acknowledges, and does not have to wait for the application to call recv).

In non-blocking mode, the send function simply copies the data to the cache area of the protocol stack. If there is not enough free space in the cache area, it will try its best to copy and return the size of the successful copy. If the free space in the cache area is 0, it will return-1 and set errno to EAGAIN.

Sysctl-an is available under linux | grep net.ipv4.tcp_wmem to view the default send cache size of the system:

Net.ipv4.tcp_wmem = 4096 16384 81920

There are three values, the first is the minimum number of bytes allocated by socket's send cache, the second is the default value (this value will be overwritten by net.core.wmem_default), the cache can grow to this value when the system load is not heavy, and the third value is the maximum number of bytes of send cache space (this value will be overwritten by net.core.wmem_max).

According to the actual test, if you manually change the value of net.ipv4.tcp_wmem, it will run according to the changed value, otherwise by default, the protocol stack usually allocates memory according to the values of net.core.wmem_default and net.core.wmem_max.

The application should change the send cache size in the program according to the characteristics of the application:

Socklen_t sendbuflen = 0

Socklen_t len = sizeof (sendbuflen)

Getsockopt (clientSocket, SOL_SOCKET, SO_SNDBUF, (void*) & sendbuflen, & len)

Printf ("default,sendbuf:%d\ n", sendbuflen)

Sendbuflen = 10240

Setsockopt (clientSocket, SOL_SOCKET, SO_SNDBUF, (void*) & sendbuflen, len)

Getsockopt (clientSocket, SOL_SOCKET, SO_SNDBUF, (void*) & sendbuflen, & len)

Printf ("now,sendbuf:%d\ n", sendbuflen)

It should be noted that although the send cache is set to 10k, in fact, the protocol stack will double it to 20k.

-case analysis-

In practical applications, if the sender is a non-blocking sender, due to network congestion or slow processing at the receiver, it usually occurs that the sending application seems to have sent 10k of data, but only 2k has been sent to the peer cache. there is still 8k in the local cache (not sent or not confirmed by the receiver). At this point, the data that the receiving application can receive is 2k. If the receiving application calls the recv function to get 1k of data in processing, at this moment, one of the following occurs:

a. The sending application thinks that send has finished 10k data and closes socket:

The sending host, as the active shutdown of the tcp, the connection will be in the semi-closed state of the FIN_WAIT1 (waiting for the other party's ack), and the 8k data in the sending cache will not be cleared, but will still be sent to the peer. If the receiving application is still in recv, it will receive the remaining 8k data (the premise is that the receiver will receive the remaining 8k data before the sender's FIN_WAIT1 status times out), and then get a message that the peer socket is closed (recv returns 0). At this point, it should be closed.

b. The sending application calls send again to send 8k of data:

If the send cache space is 20k, then the free space of the send cache is 20-8cm 12k, which is larger than the 8k of the request, so the send function copies the data and immediately returns 8192.

If the sending cache space is 12k, then send () will return 4096 if there is still 12-8cm 4k send () available at this time. After the application finds that the returned value is less than the size of the request, it can be considered that the cache is full, and it must be blocked (or wait for the next socket writable signal through select). If the application ignores it and calls send again immediately, it will get the value of-1, which will be shown as errno=EAGAIN under linux.

c. The receiving application closes socket after processing 1k data:

As the receiving host shuts down actively, the connection will be in the semi-closed state of FIN_WAIT1 (waiting for the other party's ack). Then, the sending application will receive a signal that socket is readable (usually the select call returns socket readable), but when reading it, it will find that the recv function returns 0, and the close function should be called to close the socket (send to the other party ack)

If the sending application does not process this readable signal, but in send, it should be considered in two cases. If the sender receives the RST flag, calling send,send will return-1, while errno is set to ECONNRESET to indicate that the peer network is disconnected. However, it is also said that the process will receive the SIGPIPE signal, and the default response action of this signal is to exit the process. If the signal is ignored, send returns-1. Errno is EPIPE (unconfirmed) If it is before the sender receives the RST flag, the send works as usual

In the case of non-blocking send, if send is a blocking call and happens to be blocking (for example, sending a huge buf at a time, exceeding the send cache), and the peer socket is closed, then send will return the number of bytes successfully sent. If send is called again, it will be the same as above.

d. The network of the switch or router is down:

After processing the received 1k data, the receiving application will continue to read the remaining 1k data from the cache, and then show that there is no data to read, which requires the application to handle the timeout. The general practice is to set a maximum time for select to wait. If there is still no data to read beyond this time, socket is considered to be unavailable.

The sending application will constantly send the rest of the data to the network, but it will never be confirmed, so the free space in the cache continues to be 0, which also needs to be dealt with by the application.

If the timeout of this situation is not handled by the application, it can also be handled through the tcp protocol itself, as shown in the sysctl entry:

Net.ipv4.tcp_keepalive_intvl

Net.ipv4.tcp_keepalive_probes

Net.ipv4.tcp_keepalive_time

The answer to the question about the study of send function in TCP is shared here. I hope the above content can be of some help to everyone. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.