Socket Sticky pack problem

These two days to see Csdn have some questions about the socket sticky packet, socket buffer settings, found that they are not very clear, so check the information to understand the record:

One or two simple concepts long connections with short connections:
1. Long connection

The client and the server first establish a communication connection, after the connection is established, and then the message is sent and received.

2. Short connection

The client side communicates with the server every time the message is sent and received, and disconnects immediately after the transaction is completed. This approach is often used in a point-to-multipoint
Communications, such as multiple client connections to a server.

When do I need to consider the problem of sticky bag?

1: If you use TCP to send data each time, you establish a connection with each other, and then after the two sides send a piece of data, then close the connection, so that there is no sticky packet problem (because there is only one package structure, similar to the HTTP protocol). Close connections are mostly sent by both parties to the close connection (refer to 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 such as "Hello give me sth abour yourself", and then B receives the message, then the buffer data is received, and then close the connection, so the sticky packet problem is not considered, Because everyone knows to send a certain character.
2: If send data unstructured, such as file transfer, so that the sender just send, the receiver only receive storage OK, do not consider sticky bag
3: If the two sides establish a connection, it is necessary to send different structure data after the connection, such as after the connection, there are several kinds of structure:
1) "Hello give me sth abour yourself"
2) "Don ' t give me sth abour yourself"
That way, if the sender sends this two packets in succession, the receiving party may be "Hello give me sth abour yourselfdon ' t give me sth abour yourself" so the receiver is silly, what is it going to do? Do not know, because the protocol does not stipulate such a strange string, so to deal with it sub-package, how to divide also need to organize a better package structure, it is generally possible to add a packet of data length, such as the header to ensure the reception.

Three sticky packet causes: occurs in the stream loss, UDP does not appear sticky packet, because it has a message boundary (refer to Windows network programming)
1 The sending side needs to wait for the buffer to be full before sending out, resulting in sticky packets
2 The receiver does not receive the buffer packet in time, resulting in multiple packets receiving

Workaround:
In order to avoid sticking, the following measures can be taken. One is caused by the sender of the sticky packet phenomenon, the user can be programmed to avoid, TCP provides a mandatory data transfer immediately after the operation of the instructions PUSH,TCP software received the operation instruction, the data immediately sent out, without waiting for the transmission buffer full, and the receiver caused by the sticky packet, By optimizing the program design, reducing the workload of receiving process, improve the priority of receiving process and so on, so that it can receive data in a timely manner, so as to avoid the phenomenon of sticky packet; the third is controlled by the receiver, a packet of data by the structure of the field, the human control sub-multiple reception, and then merge, through this means to avoid

The above mentioned three kinds of measures, all have their shortcomings. Although the first method of programming can avoid the sticky packets caused by the sender, it shuts down the optimization algorithm, reduces the network sending efficiency, affects the performance of the application, and is generally not recommended for use. The second method can only reduce the likelihood of sticky packets, but does not completely avoid the sticky package, when the sending frequency is high, or because the network burst may make a time period packet arrives at the receiver faster, the receiver may still be too late to receive, resulting in sticky packets. The third approach avoids sticky packets, but the application is less efficient and unsuitable for real-time applications.

Related articles interception:

A package does not have a fixed length, Ethernet limit of 46-1500 bytes, 1500 is the MTU of the Ethernet, over this amount, TCP will set an offset for IP datagrams for the Shard transfer, now generally allows the application layer to set the 8k (NTFS system) buffer, 8k of data from the underlying shards, And the application seems to be just one send. The experience value of Windows buffers is that 4k,socket itself is divided into two types, stream (TCP) and datagram (UDP), and your problem is different for both of these uses

Sample. It's even about programming with blocking or non-blocking sockets.

1, communication length, this is your own decision, no system forcing you to send how big package, the actual should be based on the needs and network conditions to decide. For TCP, this length can be a bit larger, but you know, the socket internal default send and receive buffer size is about 8K, you can use setsockopt to change. But for UDP, don't be too big, usually 1024 to 10K. Note that you no matter how big the package, the IP layer and the link layer will send your packet to be fragmented, the general LAN is about 1500, WAN is only dozens of bytes. The packet after the Shard will reach the receiver by different routes, and for UDP, if one of the shards is lost, then the receiver's IP layer will discard the entire sending packet, which forms a packet loss. Obviously, if a UDP packet like Blake Large, it is fragmented, the probability of the link layer lost shards like Blake Large, you this UDP packets, like Blake easy to lose, but too small and affect efficiency. It is best to configure this value to adjust to the optimal state according to the different environment.

The Send () function returns the actual length of the send, and in the case of the network, it will never return (send failed) errors, up to 0. For TCP You can write a loop of bytes to send. When the Send function returns SOCKET_ERROR, it marks an error. But for UDP, you do not write the loop to send, otherwise it will bring great trouble to your reception. So UDP needs to use setsockopt to change the size of the socket internal buffer to accommodate your contract. To be clear, TCP as a stream, the package will not be the whole packet arrives, but a steady flow of, that the receiver must pack. While UDP is a message or datagram, it must be the entire packet to the receiving party.

2, about the reception, the general contract has the package boundary, the first is you the length of the package to let the receiver know, so there is a Baotou information, for TCP, the receiver first receive this Baotou information, and then collect the packet data. It is also possible to collect the entire package at a time, and you can verify whether the results are received or not. This completes the package process as well. UDP, then you can only receive the entire packet. If the receive buffer you provide is too small, TCP will return the actual received length, the remaining can be received, and UDP is different, the remaining data is discarded and returned wsaemsgsize error. Note TCP, if you provide buffer like Blake Large, then you may receive multiple packages, you have to separate them, and when the buffer is too small, and at a time to receive the data inside the socket, then the socket receive event (OnReceive), may not be triggered again, Pay close attention to this when using event mode for reception. These features represent the difference between a stream and a packet.

Related Reference articles:
Http://www.cnblogs.com/alon/archive/2009/04/16/1437600.html

Socket Sticky pack problem