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@compacsort.com>:
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@lists.boost.org 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