Hi guys , i write this message for a doubt, a time ago i wrote a client/server program with TCP/IP in Linux. When i tested the program flooding the server with messages of 1024 bytes (Or 1025 bytes i dont remember exactly the number but was more that 1000 bytes) in certain point a message was received truncated blocking the program because the while(recv) never completed the 1024 characters count. I avoided this problem making the messages more shorter (i don't remember 200 bytes i guess) but i know that is not ok. Now i must develop a very strong connection (avoiding so much as posible the lost of messages) and i need understand why this happened and how avoid this problem. Maybe the net was oversaturated in that moment when i tested my program and a part of the message was lost but this is not a excuse. My question is �There is some protocol that avoid the lost packages (i know that tcp does the best effort for send the message but i saw how a message or part of it came truncated more than once) or either very strong or I must develop a protocol for this?
I read about Reno TCP and TCP Vega but really i dont know how use it.
TCP doesn't truncate, it fragments. Messages will arrive in multiple pieces. The sending and receiving programs don't have control of how many or what size.
If you require packets to arrive in specific sizes, use UDP. Packets larger than the MTU simply won't work at all.
It is a very good point the MTU length, first of all thank you for this info because I didn't know , but when I tested the program, many messages arrived to the server , before the incomplete message i guess that the large of the message was more large that the message because even the first message should not have come.
TCP is not received in dependably-sized chunks, it is a stream. If they sent 30 bytes and you only read 2, that's okay, just read 28 more. Conversely, if they sent 5000 bytes and you got 1000, just keep reading, you'll get the rest eventually.
If the lengths are variable, you should encode them as part of the stream. Otherwise you won't know how much to expect and, as you've discovered, getting the "right" size from recv() is not dependable, mostly because there is no such thing.
I'm guessing you overloaded it until it was unable to cope. It started delivering data immediately instead of bundling multiple packets together politely.
Or, the server might even have been running out of memory. No kind of connection can cope with that. Each TCP connection takes a good chunk of it.
Sorry Corona , Do you want to say that i have wait a time before send a new message to the server and in this way do not overload the server or the connection?
The server wasn't out of memory.... i guess.. but is a very good point.