TCP Sticky Packet Analysis

These two days to see csdn some of the socket sticky packet, socket buffer settings, found that they are not very clear, so check the data to understand the record:

One. Two simple concept long connection with short connection:
1. Long connection

Client side and server to establish a communication connection, the connection is established to open, and then send and receive messages.

2. Short connection

The client side communicates with server every time a message is sent and received, and the transaction is immediately disconnected. This approach is often used in a little bit of
Communications, such as multiple client connections to a server.

Two. When do I need to consider the sticky bag problem?

1: If you use TCP to send data each time, you establish a connection with each other, and then the two sides send out a piece of data, then close the connection, so there will be no sticky problem (because there is only one package structure, similar to the HTTP protocol). Close the connection primarily to both sides send a close connection (refer to the TCP shutdown protocol). Such as: a need to send a string to B, then A and B to establish a connection, and then send both sides of the default good protocol word Furu "Hello give me sth abour yourself", and then B received the message, the buffer data received, and then closed the connection, so the sticky problem does not take into account Because everyone knows to send a piece of character.
2: If the sending data without structure, such as file transfer, so that the sender just send, the receiver only to receive storage on OK, also do not consider the sticky package
3: If the two sides establish a connection, need to send a period of time after the connection of different structural data, such as after the connection, there are several structures:
1) "Hello give me sth abour yourself"
2) "Don ' t give me sth abour yourself"
That way, if the sender sends this two packets continuously, the receiver may be "Hello give me sth abour yourselfdon ' t give me sth abour yourself" so that the receiver will be silly, exactly what to do. Do not know, because the protocol does not prescribe such a strange string, so to deal with it subcontracting, how to divide also need to organize a better package structure, so generally may be in the header plus a data length of the package, to ensure that receive.

Three. The reason of sticky package: In the transmission, UDP will not appear sticky package, because it has a message boundary (refer to Windows network programming)
1 The sender need wait buffer full before sending out, causing the sticky package
2 receiver does not receive buffer packets in time, causing multiple packets to receive

Solution:
In order to avoid the sticky phenomenon, the following measures can be taken. One is for the sender caused by the phenomenon of sticky packets, the user can avoid by the programming setting, TCP provides the operation instruction that forces the data to send immediately push,tcp the software receives the operation instruction, immediately sends this data out without waiting for the sending buffer to fill, and the second is the sticky package caused by the receiver, Can be optimized by programming, streamline the receiving process workload, improve the receiving process priority and so on, so that it receives data in time, so as to avoid the phenomenon of sticky packets; third, by the receiver control, a packet of data by the structure of the field, the artificial control of multiple received, and then merged, through this means to avoid sticky packets

The three measures mentioned above have their drawbacks. The first programming setting method avoids the sticky packets caused by the sender, but it turns off the optimization algorithm, reduces the efficiency of the network transmission, and affects the performance of the application, which is generally not recommended. The second method can only reduce the likelihood of sticking, but can not completely avoid the sticky packet, when the sending frequency is high, or because the network burst may make a time packet to reach the receiver faster, the receiver is still likely to be too late to receive, resulting in sticky packets. The third method avoids the sticky package, but the application is less efficient and unsuitable for real-time applications.
Download from: http://blog.csdn.net/binghuazh/archive/2009/05/28/4222516.aspx
====================================================================
Packet and unpacking collections for network communications

For communication programs based on TCP development, there is a very important problem to be solved, that is, the encapsulation and unpacking.

Why does a TCP based communication program need to be wrapped and unpacking?

TCP is a "stream" protocol, called a stream, which is a string of data without boundaries. We can think of the water in the river, is connected into one, there is no dividing line. However, the general Communication program development is to define a separate packet of data, such as for landing packets, for cancellation of packets. Due to TCP "stream "Features and network conditions, there are several situations in which data transfer occurs.
Let's say we call two times in a row send two pieces of data data1 and data2, at the receiving end has the following kinds of reception (of course, there are more than that, here are only a representative case).
A. Receive the DATA1 first, then receive the DATA2.
B. Receive part of DATA1 data first, then receive the rest of Data1 and data2.
C. Receive all the data of data1 and Data2, and then receive the remaining data of data2.
D. All data for Data1 and Data2 were received at once.

For a This situation is exactly what we need, no more discussion. For the b,c,d of the situation is that we often say "sticky bag", we need to receive the data for unpacking, split into a separate packet. The packet must be marshaled at the sender for unpacking.

Another: For UDP there is no problem of unpacking, because UDP is a "packet" protocol, that is, two of the data between the boundaries, at the receiving end either receive data or receive a complete piece of data, will not receive less and more receive.

Two. Why there is a b.c.d situation.
"Sticky packs" can occur on the sender or on the receiving end.
1. The sticky packet of the sender caused by the Nagle algorithm: Nagle algorithm is an algorithm to improve the efficiency of network transmission. Simply put, when we submit a piece of data to TCP, TCP does not send this data immediately, but rather waits a short time to see if there is still data to send during the wait. If it does, it will send the two pieces of data at once. This is a simple explanation of the Nagle algorithm, please read the relevant books. Like C and D, it could be the result of a Nagle algorithm.
2. Receiving end to receive the receiving end of the sticky package: TCP will have the data received in its own buffer, and then notify the application layer to fetch the data. When the application layer is unable to retrieve TCP data in time due to some reasons, it will cause a few data to be stored in the TCP buffer.

Three. How to seal and disassemble the package.
   When I first encountered a problem with "sticky packs," I was sleeping for a short period of time by calling sleep between send and two. The disadvantage of this solution is obvious, which makes transmission efficiency much lower and unreliable. And then it was solved by answering, Although most of the time is feasible, but can not solve the situation like B, and the response to increase the amount of traffic, aggravating the network load. Then it is the operation of marshaling and unpacking packets.
    Package:
Packet is to a piece of data with a header, so that the packet is divided into Baotou and the package of two parts of the contents of the packet (in the future, when the packet filtering illegal packets will be added to the "package tail" content). Baotou is actually a fixed size structure, There is a struct member variable representing the length of the package, which is a very important variable, and other members of the struct can be defined on their own. A complete packet can be split correctly according to the length of the header and the variable in the header containing the length of the package.
    for unpacking at the moment, my most common use is the following two ways.
    1. Dynamic buffer staging mode. The buffer is dynamic because it increases the length of the buffer when the length of the buffer is exceeded. The
    approximate process description is as follows:
    A, dynamically allocating a buffer for each connection, and associating this buffer with the socket, commonly associated with the struct body.
     B, when the data is received, the data is first stored in the buffer.
    C, to determine whether the data in the buffer is sufficient for the length of a header, if not enough, then do not perform a unpacking operation.
    D, the variables that represent the length of the package are parsed from the header data.
    E, to determine whether the length of the data in the buffer, except Baotou, is sufficient for the length of a package, if not enough, the unpacking operation is not performed.
    F, remove the entire packet. The "fetch" here means not just copying packets from the buffer, but removing the packet from the cache. The way to delete this is to move the data behind the packet to the starting address of the buffer.

This approach has two drawbacks. 1. Dynamically allocating a buffer for each connection increases the use of memory. 2. There are three places to copy data, a place to store data in a buffer, and a place to take the complete packet out of the buffer. One place is to remove packets from the buffer. The second method of unpacking solves and perfects these drawbacks.

The disadvantages of this method have been mentioned earlier. An improved approach, which uses circular buffering, is given below. But this improvement does not solve the first shortcoming and the first copy of the data, only the third place of the data copy (this is the place where the most copies of data). The 2nd method of unpacking solves both problems.
The loop buffer implementation is defined as two pointers, pointing to the head and tail of the valid data. When data is stored and data is deleted, only the end-and-tail pointer moves.

2. Use the underlying buffer to carry out the unpacking
Since TCP also maintains a buffer, we can use TCP buffers to cache our data so that we do not need to allocate a buffer for each connection. On the other hand, we know that recv or wsarecv have an argument, Used to indicate how long we want to receive data. Using these two conditions, we can optimize the first method.
For blocking sockets, we can use a loop to receive data from the header length, then parse out the variable representing the length of the package, and then use a loop to receive the packet length data.
The relevant code is as follows:

Char packagehead[1024];
Char packagecontext[1024*20];

int Len;
Package_head *ppackagehead;
while (M_bclose = = False)
{
memset (packagehead,0,sizeof (Package_head));
Len = M_tcpsock.receivesize ((char*) packagehead,sizeof (Package_head));
if (len = = socket_error)
{
Break
}
if (len = = 0)
{
Break
}
Ppackagehead = (Package_head *) Packagehead;
memset (packagecontext,0,sizeof (Packagecontext));
if (ppackagehead->ndatalen>0)
{
Len = M_tcpsock.receivesize ((char*) packagecontext,ppackagehead->ndatalen);
}
}

M_tcpsock is a variable of a class that encapsulates a socket, where the receivesize is used to receive a certain length of data until a certain length of data is received or a network error is returned.

int Winsocket::receivesize (char* strdata, int ilen)
{
if (strdata = NULL)
return err_badparam;
char *p = strdata;
int len = Ilen;
int ret = 0;
int returnlen = 0;
while (Len > 0)
{
ret = recv (M_hsocket, p+ (Ilen-len), Ilen-returnlen, 0);
if (ret = Socket_error | | ret = 0)
{

return ret;
}

Len-= ret;
Returnlen = ret;
}

return Returnlen;
}
For non-blocking sockets, such as completion ports, we can submit a request to receive data for the length of the header, and when GetQueuedCompletionStatus returns, we determine whether the received data length is equal to the length of the header, and if so, submit a request for data receiving the packet length, If not equal, submit a request to receive the remaining data. A similar method is used when receiving the package body.

Download from: http://blog.csdn.net/fjcailei/archive/2009/06/17/4276463.aspx
======================================================================
A few questions: http://www.qqgb.com/Program/VC/VCJQ/Program_200509.html
This problem arises from several problems encountered in programming:
1, the use of TCP socket to send data, there will be send error, Wsaewouldblock, in TCP is not guaranteed to send the data can safely reach the receiver side. Also has the window mechanism to prevent sends the speed to be too fast, why also can make mistakes.

2, TCP protocol, in the use of sockets to send data, each send a packet, the receiver is complete to accept a package or what. If it is every packet, accept a package, why there will be sticky problem, how the specific operation.

3, about send, is not only in the non-blocking state will appear actually sent than the specified send the small. In the blocking state will not appear to actually send the smaller than the specified send, that is, can only appear or send all, or not send. In a non-blocking state, if it sends some data, what to do, call the Send function, find the return value is smaller than specified, how to do.

4, the last question, is the TCP/IP protocol and socket is what relationship. Refers to the implementation of the specific, socket is the implementation of TCP/IP. So why does it appear that the socket using the TCP protocol sends an error (back to the first question, Khan)

It is a bit dizzy, if my problem has not clear the place, or scores have problems, please note, thank you

The 1th answer to this question is:
1 should be your buffer is not big enough,
2 TCP is a stream, no bounds. Also known as the package.
3 blocking will also appear this phenomenon, after the occurrence of the send did not send out.
4 TCP is a protocol, the socket is an interface, not necessarily connected. The error depends on the problem you use the interface, and TCP does not matter.

The 2nd answer to this question is:
1 should be your buffer is not big enough,
2 TCP is a stream, no bounds. It doesn't matter.
3 blocking will also appear this phenomenon, after the occurrence of the send did not send out.
4 TCP is a protocol, the socket is an interface, not necessarily connected. The error depends on the problem you use the interface, and TCP does not matter.

The 3rd answer to this question is:
1, should not be the buffer size problem, I tried to set the buffer size, but here is the problem, even if I set the buffer to a few g, also return to success, but in fact how can be set so large 、、、

3, there is no time to send the end of the manual, there is no specific code to achieve.

4, when the choice of TCP socket to send data, TCP window mechanism is not able to prevent the transmission speed too fast. Why the socket has not been processed after Wsaewouldblock appears.

The 4th answer to this question is:
1. In the case of using non-blocking mode, if the system sends a buffer full and sends it to the right side in a timely manner, this error will occur and continue to retry.
3. If not, continue to send the following parts.

The 5th answer to this question is:
1, when using non-blocking mode, if the current operation can not be completed immediately will return failure, error code is wsaewouldblock, this is normal, the program can perform other tasks, after a period of time and then retry the operation.
2, send and receive is not one by one corresponding, TCP will send each of the data to regroup, may merge may also split, but the order of delivery is unchanged.
3, in all cases, according to the return value of Send to determine how much data sent, did not send the end of the hair.
4, the socket is Windows provides network programming interface, TCP/IP is a network transport protocol, the use of sockets can use a variety of protocols, including TCP/IP.

The 6th answer to this question is:
Up the 7th answer to this question:
The process is sent to the buffer and sent from the buffer to the network
Wsaewouldblock and sticky packets are all present in the process of sending to the buffer.