Not sure if anyone replied yet or not
...
>> ... protocol that puts a prefix on each message
indicating the number its bytes number.
Yes, a fairly common design (I've done a variation
on it at least a dozen times).
>> ... errors related to reading a prefix that would indicate a
strange number of bytes incoming, a number that was far greater than the max
size possible of message ...
Also pretty common problem. I'd bet a major body
part there's a bug in the sending (or receiving) side of the app. Something has
dropped some bytes somewhere, or lost track of where it is in the "message
framing".
>>... So i reduced the socket buffer size to 1K, and the
application crashed with a lot less network load than before. ... At the moment,
i am almost sure that the problem is the socket receive buffer which overflows
and the bytes are discarded, creating a "gap" in the byte stream which causes an
inconsistent state on the application.
As mentioned, you're probably on the mark as to why
you're crashing. But not as to the underlying cause.
You're focusing on an OS or TCP stack problem,
rather than your code. The TCP protocol has "flow control" built in, and if the
receiving side fills up or is congested, it will tell the sending side to quit
sending. If packets get dropped while the flow control is "kicking in", the
packets will (eventually) get re-transmitted. (On a side note, this type of
congestion can be a system-level problem, with certain use cases.)
>> ... What should happen when
the socket receive buffer overflows? It silently discards the bytes or
what?
TCP never "silently discards" bytes (UDP
will, obviously). There's a bug in your code (including the way you're using
Asio).
Asio streambufs or iostreams can leave characters
in the buffer, and your logic must account for these.
If you're still having the problem, reduce your
code to the smallest example that will reproduce the crash, and post it to the
mailing list (there's also an Asio mailing list you can use).
Cliff