Subject: Re: [boost] [asio] Randomly having problems reading from the socket
From: Torben Wiggerich (torben.wiggerich_at_[hidden])
Date: 2011-05-09 04:01:50
Am 05.05.2011 16:30, schrieb Cliff Green:
> The symptoms you describe, based on the code you included in your
> first e-mail, seems to point to a simple and straightforward problem -
> you're running into TCP flow control blockage. This is a traditional
> TCP problem and is not directly related to Asio.
> Anytime you're sending data as fast as possible, and the receiving
> side is just slightly slower at receiving the data, send buffers in
> the OS will fill up. Eventually this will result in the send being
> blocked for a short period of time while the receiving side processes
> the data. If you're using blocking writes, the send will block for a
> period of time. If you're using async writes, the write completion
> handler will take longer before it is called (which is why I greatly
> prefer async operations all around).
> That the problem is transitory and takes a while to manifest is
> another clue - it depends totally on how fast the sending and
> receiving applications are running, and if there's a short period on
> the receiving side where the app can't run as fast (e.g. another app
> takes up some processing time), the blockage will be transitory.
Thanks for your answer and Sorry for my late response...
So I will give the asynchronous connection a try ...
If I understand you correct, just the sender should be blocked for a
time. You say that it is because the buffers are running full. Is there
a method to detect if the buffers are full, so that I should stop
sending new packets? It would be ok if it stops for a few milliseconds,
but not for a such long time like 5 seconds...
But I also don't understand how both sides can stop receiving and
sending data for 5 seconds at the same time...
On the other hand the application where I observed this error didn't
produce so frequently network traffic at all. It produces this packages
only with 25 Hz...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk