Boost logo

Boost Users :

Subject: Re: [Boost-users] Boost.ASIO stuck on some requests?
From: Matthieu Brucher (matthieu.brucher_at_[hidden])
Date: 2016-11-09 19:06:28


Thanks for all the tips, I had indeed a remaining sync call (after a HTTP
reauest, I asked for the remaining data in a sync way intead of doing
another async read!). Now it works full speed :)
Indeed, keeping the connection is a good idea, I'll tell my clients to do
so as well!



2016-11-09 22:40 GMT+00:00 Gavin Lambert <gavinl_at_[hidden]>:

> 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:
> rview/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.
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]

Information System Engineer, Ph.D.

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