[cpp-netlib-devel] async keepalive and other things

[Rick R. <ric...@gm...>]

Three things:

1. Hi, I'm Rick Richardson.  I just got a hold of cpp-netlib because I am
looking to make a highly scalable and runtime reconfigurable reverse proxy.
I am fairly new to boost::asio but have been doing event driven network
coding for 10 years.  I still don't fully understand the netlib source so if
my approach is way off, please forgive me.


2. I added keepalive capabilities to the async server. I altered the
existing async server because I don't see how any self respecting server
wouldn't offer keepalive :)

My approach:  I wrapped the chain of async functions back around to call
read_more. Specifically, in server/async_connection.hpp, in write(Range) I
register a callback to be read_more_wrapper(), which does the work of
default_error() and then calls read_more.  This is to handle requests that
may be pipelined over the same connection. Since this callback is carried
through to be executed after all writes have completed. It should be safe to
handle pipelined requests in a serial fashion.

If there are no pending additional requests, then the async_read_some will
block indefinitely.

The second phase of the plan, then, is to register a deadline timer at start
of the new connection. Every new request that gets read will kick the
deadline timer back up to its max timeout time.  When the timer does go off,
it cancels any operations that are pending on the Connection's socket.
This does two things, first and foremost, it keeps a hold of the
Connection's shared ptr, so that it is guaranteed not to be destroyed while
the keepalive is in effect.  Secondly, it quite obviously will free the
async_read_some from its wait.

I haven't bothered to fork cpp-netlib on github so I don't have a checkin to
make, but I did create a 'git diff' from  boost/   I have attached it here
for your perusal.
Please let me know your preferred approach for reviewing and accepting
patches (I am assuming a pull request, which I can get around to)


3.  In attempting to benchmark my changes.  I did note that yes, keepalive
works, and also that it breaks httperf.  My problem is that httperf doesn't
seem to recognize a completed response unless the server closes the
connection.  It claims to be a 1.1 compliant tester, and when it sends
requests it doesn't mention a connection: close in its headers, so I'm
assuming it should expect the connection to remain open.

Does anyone know the correct procedure here, or why it might be thinking
that the responses have not completed?  My concern here is that there is
some nuance of the HTTP 1.1 spec that I may have missed which allows servers
to delineate between responses since, with pipelining, multiple responses
may come all at once over the same connection.


Thanks,
Rick Richardson