Re: [Boost-users] Boost.ASIO stuck on some requests?

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:

http://www.boost.org/doc/libs/1_62_0/doc/html/boost_asio/overview/core/handler_tracking.html

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.