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

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

Hi,

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!

Regards,

Matthieu

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:
>
> http://www.boost.org/doc/libs/1_62_0/doc/html/boost_asio/ove
> 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]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>

-- 
Information System Engineer, Ph.D.
Blog: http://blog.audio-tk.com/
LinkedIn: http://www.linkedin.com/in/matthieubrucher