Tcp udp sending Buffer

Note that not sending transmits the data in the sending buffer of S to the other end of the connection, but the Protocol. Sending only copies the data in the Buf to the remaining space of the sending buffer of S.

 

The data sent by TCP to the other party. When receiving the data, the other party must confirm with the spear. Only when receiving the confirmation from the other party, the TCP will delete the data in the TCP sending buffer.

 

Because UDP is an unreliable connection, you do not have to save the data copies of the application process. When the data in the application process is passed down along the protocol stack, It is copied to the kernel buffer in some form, when the data link layer transfers data, the data in the kernel buffer is copied and deleted. Therefore, it does not need a sending buffer.

 

In blocking mode, the send function copies the data sent by application requests to the sending cache for sending, and returns the data after confirmation. however, the existence of the sending cache shows that if the size of the sending cache is greater than that of the request, the send function returns immediately and sends data to the network. Otherwise, send sends the part of data that cannot be contained in the cache to the network, and waits for confirmation from the peer end before returning the data. (the receiving end only needs to receive the data in the cache and confirms it, does not have to wait for the application to call Recv );

In non-blocking mode, the send function only copies data to the cache area of the protocol stack. If the available space in the cache area is insufficient, you can do your best to copy the data, the size of the successful copy is returned. If the available space in the cache area is 0,-1 is returned, and errno is set to eagain.

 

In Linux, use sysctl-A | grep net. ipv4.tcp _ WMEM to view the default sending cache size:
Net. ipv4.tcp _ WMEM = 4096 16384 81920
There are three values. The first value is the minimum number of bytes allocated in the socket sending cache, and the second value is the default value (this value will be net. core. wmem_default overwrite). The cache can be increased to this value when the system load is not heavy. The third value is the maximum number of bytes in the sending cache space (this value will be net. core. wmem_max overwrite ).
According to the actual test, if the net. net. the value of ipv4.tcp _ WMEM is run according to the changed value. Otherwise, the protocol stack is usually based on net. core. wmem_default and net. core. the value of wmem_max to allocate memory.

The application should change the sending cache size in the program according to the application features:

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 sending cache is set to 10 K, the protocol stack actually doubles it to 20 K.

 

 

Use a non-blocking socket in Linux.

(1) sending

When the customer sends large data packets through the send function provided by socket, an eggain error may be returned. This error occurs because the size variable in the send function exceeds the value of tcp_sendspace. Tcp_sendspace defines the amount of data that the application can cache in the kernel before calling send. If the o_ndelay or o_nonblock attribute is set in the socket, The eagain error is returned if the sending cache is full.

To eliminate this error, you can select one of the following three methods: 1. Increase tcp_sendspace so that it is greater than the size parameter --- no-p-o tcp_sendspace = 65536 in send.
2. Before sending, set a greater value for sndbuf in the setsockopt function.
3. Replace send with write because write does not set o_ndelay or o_nonblock.

(2) Receiving

When receiving data, the error message "resource temporarily unavailable" is often reported. The errno code is 11 (eagain ). This indicates that you have called the blocking operation in non-blocking mode. If the operation is not completed, this error is returned. This error will not damage the synchronization of the socket, the next cycle is followed by Recv. For a non-blocking socket, eagain is not an error. On VxWorks and windows, eagain is named ewouldblock. In fact, this is not an error, but an exception.

 

Use a non-blocking socket in Linux.

(1) sending

When the customer sends large data packets through the send function provided by socket, an eggain error may be returned. This error occurs because the size variable in the send function exceeds the value of tcp_sendspace. Tcp_sendspace defines the amount of data that the application can cache in the kernel before calling send. If the o_ndelay or o_nonblock attribute is set in the socket, The eagain error is returned if the sending cache is full.

To eliminate this error, you can select one of the following three methods: 1. Increase tcp_sendspace so that it is greater than the size parameter --- no-p-o tcp_sendspace = 65536 in send.
2. Before sending, set a greater value for sndbuf in the setsockopt function.
3. Replace send with write because write does not set o_ndelay or o_nonblock.

(2) Receiving

When receiving data, the error message "resource temporarily unavailable" is often reported. The errno code is 11 (eagain ). This indicates that you have called the blocking operation in non-blocking mode. If the operation is not completed, this error is returned. This error will not damage the synchronization of the socket, the next cycle is followed by Recv. For a non-blocking socket, eagain is not an error. On VxWorks and windows, eagain is named ewouldblock. In fact, this is not an error, but an exception.

 

In addition, if eintr is returned, that is, errno is 4, and the error description is interrupted system call, the Operation should continue.

Finally, if the return value of Recv is 0, it indicates that the other party has disconnected, and our receiving operation should also end.