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