Boost logo

Boost Users :

Subject: Re: [Boost-users] Boost.ASIO stuck on some requests?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-11-09 17:40:51

On 9/11/2016 22:17, Matthieu Brucher wrote:
> I have an app that serves different clients and it is based on Boost.ASIO.
> My current issue is that if the first client is fast enough (a
> continuous fast loop with Python module requests), then the other
> clients may time out with no good reason when trying to connect.
> Is there a way of figuring out who is actually waiting on who? Maybe the
> clients are starved because of an issue on their box, or there is an
> issue in ASIO that serves always the first connection? Or is it Windows?
> I tried multithreading the server, but that didn't help, and a run with
> VTune Amplifier shows me that the app is mainly waiting.
> But if I add a 100ms sleep between requests, then everything is fine.
> But this is not an acceptable solution, as the clients in real life will
> want to launch requests all the time.

This might be of use:

In general though, make sure that you are using async methods rather
than sync ones, and that when your accept handler is called you
immediately launch another async_accept.

Having said that, there is a name for a client making continuous
connection requests to a single server without pausing: a Denial of
Service attack. Make sure that your client is fully completing a
request before starting a new one, and that if requests are completed
sufficiently fast that waiting for completion is not in itself a
sufficient delay, then you'll need to throttle its retry rate.

If you want to perform many rapid data transfers, then consider a
protocol that maintains a connection rather than continually
reconnecting; transferring data over an existing connection is far
friendlier to both server and client than constantly breaking and
re-making the connection.

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at