Subject: Re: [boost] [asio] Randomly having problems reading from the socket
From: Torben Wiggerich (torben.wiggerich_at_[hidden])
Date: 2011-05-10 03:53:56
Am 09.05.2011 18:05, schrieb Cliff Green:
> From: "Torben Wiggerich" <torben.wiggerich_at_[hidden]>
>> 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?
> Not that I know of (someone else may have some suggestions). If you're
> using blocking writes, you may have blockage.
>> It would be ok if it stops for a few milliseconds, but not for a such
>> long time like 5 seconds...
> Yeah, it seems excessive to me, too. I would guess there's something
> else at play. Maybe when TCP flow control kicks in, there's some kind
> of driver reset or timeout that is occurring.
>> But I also don't understand how both sides can stop receiving and
>> sending data for 5 seconds at the same time...
> That also seems odd - I would expect just the receiving side to pause.
> So, as already mentioned, maybe something else odd is occurring.
> Have you put an analyzer (e.g. WireShark) on it and watched the TCP
> packets from right before and when the pause occurs? This might help
> isolate the problem.
Ok I will try this...
>> 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...
> I don't understand what you mean.
In the example program I gave was the sender sending continously without
any pausing. I just wanted to say that it even occours if the sender is
not sending which such a high frequency. What speaks a little bit
against the theroy that a buffer is running full. (I didn't try to
reproduce this with the example program.) But that is just speculative.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk