Am 09.05.2011 18:05, schrieb Cliff Green:
From: "Torben Wiggerich" <torben.wiggerich@nisys.de>
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. Torben