Turn to a question about socket TCP message loss:
Server and the client message processing through the message queue, structure the message through the boost serialization, again with the length of the message ID information such as the structure into a smart pointer object, put the object in sending a message queue, send a message thread, every 5 ms remove an object from the queue, access to object serialized string, splicing serialized header, string segmentation, such as structure into a complete message string, and then call the send send the string, serialized each message can be made to the message from the string ID key strings,
Problem is, through the send function return values, can be sure to send the rules about the number of messages, but from the string of recv receives the search keyword message ID, number but do not agree with the number of sending,
Because of the company code doesn't get outside net, so I'll probably use pseudo code description:
Pack (from pMessage)
{

Serialize the message header (MessageHeadStruct) +
Split string +
PMessage - & gt; GetMessageBuffer (); \ \ message structure serialized string
Complete the return buffer
}
Send (buffer, length)

Beg god for help

CodePudding user response:

Is your network real-time Ethernet? If not, how do you guarantee packets sent and received at the end of the synchronization of real-time? Even without a local area network (LAN) VLAN with straight ping ping packets cannot guarantee the accuracy,

CodePudding user response:

Send frequency drop a drop hair, take a look at how many sending frequencies can achieve stable receiving, then under the condition of different network to test the frequency thresholds, finally according to the distribution of threshold value to determine the procedures of performance indicators or claim to the network conditions

CodePudding user response:

TCP packet loss will prompt error, program didn't you receive the pack is complete, you need to joining together packages,

CodePudding user response:

Should be like the picture, a fast figure is picture can be formed, but the buffer and speed have a behind would be a tear,
So can see compression, or reduce stress buffering and speed to slow down the transfer process,

CodePudding user response:

I have also questioned the TCP packet loss, and later found that the code is not perfect, such as receiving lag, stick package, or the control character and general data is similar, may appear problem,

CodePudding user response:

First determine the TCP is a reliable, not lost package, secondly you this kind of situation, should be logically wrong, such as sending time will not because the network reason, complete when sending data accumulation, the business layer directly rejected part of the package, or it may be a receiver, accept too many package, processing speed is slow, the receiver business layer rejected part of the package, because sometimes the video transmission will use packet loss at that time to deal with, after all part of the package does not affect the screen display, colleagues can relieve network and performance of the problem, depending on your code, how to deal with in the train of thought for reference only,

CodePudding user response:

TCP is a reliability, not lost package,

CodePudding user response:

TCP not packet loss UDP will throw
Create the receive buffer, will certainly carry length header, recognition to the full packet length to unpack again