The processing method of sticky packet and half package in TCP

A TCP sticky packet is a packet of packets sent by the sender to the receiver when it is received, viewed from the receive buffer, followed by the head of the packet data immediately preceding the end of the packet.

The cause of the sticky packet phenomenon may be caused by the sender or by the receiver.
The sticky packets caused by the sender are caused by the TCP protocol itself, and TCP is often needed to collect enough data to send a packet of data to improve transmission efficiency. If the data sent several times in a row is very small, usually TCP will be based on the optimization algorithm to synthesize the data packets sent out once, so that the receiver received the sticky packet data.
The sticky packet caused by the receiver is due to the fact that the receiver user process does not receive the data in time, resulting in sticky packets. This is because the receiver first put the received data in the system receive buffer, the user process from the buffer to fetch data, if the next packet of data arrives before a packet of data has not been taken away by the user process, the next packet of data into the system receive buffer when the previous packet of data is received, The user process takes data from the system receive buffer based on the pre-set buffer size, so that it takes more than one packet of data at a time.

The solution for C + + is as follows:

Receiving end
int irecvsize = packtesize + 10;
int iRet;
int idx = 0;
while (Irecvsize > 0)
{
IRet = recv (AcceptSocket, Recvbuf+idx, irecvsize, 0);
if (IRet > 0)
{
IDX + = IRet;
Irecvsize-= IRet;
}
else if (IRet = = 0)
{
Break
}
else if (IRet = = socket_error)
{
Break
}
}
Send side:
int isendsize = packetsize + 10;
int isent;
int idx = 0;
while (Isendsize > 0)
{
Isent = Send (m_socket,sendbuffer+idx,isendsize,0);
if (isent > 0)
{
IDX + = Isent;
Isendsize-= isent;
}
else if (isent = = 0)
{
Break
}
else if (isent = = socket_error)
{
wprintf (L "Send failed with Error:%d\n", WSAGetLastError ());
Closesocket (M_socket);
WSACleanup ();
Break
}
}
If the transmitted data is a continuous stream of data without structure (such as file transfer), it is not necessary to separate the packets of adhesion (for short), but the other is to subcontract.

C # uses the available member of the socket to indicate whether there is data to be read, and if available>0, indicates that there is still data to read, whereas read is done.

public class Connectinfo
{
Public ArrayList tmplist {get; set;}
Public SocketAsyncEventArgs Sendarg {get; set;}
Public SocketAsyncEventArgs Receivearg {get; set;}
Public Socket ServerSocket {get; set;}
Public User user = new user ();

}

if (client. Available > 0)
{
Console.WriteLine ("Sticky package processing");
for (int i = 0; i < rec; i++)
INFO.TMPLIST.ADD (Datas[i]);
Array.clear (datas, 0, Datas. Length);

Datas = new Byte[client. Available];
E.setbuffer (datas, 0, Datas. Length);
Client. Receiveasync (e);

}
Else
{
Check the ArrayList of the staging data, there is no data, and this time the data merge
if (Info.tmpList.Count > 0)
{
for (int i = 0; i < rec; i++)
INFO.TMPLIST.ADD (Datas[i]);
Datas = Info.tmpList.ToArray (typeof (Byte)) as byte[];
rec = datas. Length;
}

Processing of the complete data received
}

The half-pack, as the name implies, is not a complete package, after TCP emits a segment, it initiates a timer, waiting for the destination to acknowledge receipt of this message segment. If a confirmation cannot be received in time, the message segment will be re-sent.
A common solution is to develop a canonical data transfer format.

As long as you control the length of the bytes you need to read, it's OK.
For example, a packet has 10 bytes, the header 4 bytes is the length, the package body 6 bytes is the package content
The first thing you have to read is 4 bytes, and if not enough, wait for the next recv return.
Enough 4 bytes, you can get the length of the packet, if more than 4 bytes, also only take 4 bytes, the more content is the package body, the later processing
And then this 4-byte content, gets 6, indicates that there is a 6-byte package behind it.
Then read 6 bytes, still if not enough to wait for the next recv return
Until it's 6 bytes enough,
If you read 6 bytes and you have extra, that's the data for the next packet.