oops..
I left out a if (error != boost::asio::error::operation_aborted) ...
from the handle_timer function.. I was playing with some things and forgot
to put this back in. Leads to erratic behavior when this is not present :)
On Sun, Mar 20, 2011 at 12:11 PM, Rick Richardson <[email protected]
> wrote:
> 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
>
>
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Cpp-netlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
