librelist archives

why doesn't register.c track the whole connection object?

From:

Ryan Kelly

Date:

2011-02-02 @ 11:57

Hi All,


  Slowly getting to grips with the Mongrel2 sources - fortunately for me
they read like a book!  Thanks Zed.

  I noticed that the machinery in "register.c" that keeps track of
active connections only tracks the underlying file descriptor for the
connection, not the entire Connection struct.  Why?

  I've identified two instances where it would be useful to map from a
connection id back to the full connection struct, or at the very least
to its IOBuf.  One's a feature enhancement, and one I think is a
definite bug.


  1)  Handlers can't respond over SSL

 The code for delivering responses from handlers to a connection uses
Register_fd_for_id() to map from a connection ID back to the socket file
descriptor, then writes the data into that file descriptor via
Connection_deliver.

  This works fine for raw HTTP, but for an SSL connection it ends up
sending unencrypted data out over the socket, which doesn't work so
well...


  2)  The control port could be much more informative

  I'm implementing a timeout service via the control port, but the only
info the control port provides is the connection id, file descriptor and
ping time.  It would be useful to know e.g. time since last read, time
since last write, number of bytes read/written, and other metadata about
each connection.

  Seems like having access to the full Connection struct would be a good
first step towards providing this info.


  So, what downsides are there to changing the REGISTRATIONS array to
map from fds to connection structs?  Or, is there another way to get
what I want in the instances above?


  Happy to have a go at this myself, with a few pointers from the
experts.


  Cheers,

    Ryan


-- 
Ryan Kelly
http://www.rfk.id.au  |  This message is digitally signed. Please visit
ryan@rfk.id.au        |  http://www.rfk.id.au/ramblings/gpg/ for details

On Wed, 2011-02-02 at 22:57 +1100, Ryan Kelly wrote:
>
>   I noticed that the machinery in "register.c" that keeps track of
> active connections only tracks the underlying file descriptor for the
> connection, not the entire Connection struct.  Why?
> 
>   I've identified two instances where it would be useful to map from a
> connection id back to the full connection struct, or at the very least
> to its IOBuf.  One's a feature enhancement, and one I think is a
> definite bug.
> 
> 
>   1)  Handlers can't respond over SSL
> 
>  The code for delivering responses from handlers to a connection uses
> Register_fd_for_id() to map from a connection ID back to the socket file
> descriptor, then writes the data into that file descriptor via
> Connection_deliver.
> 
>   This works fine for raw HTTP, but for an SSL connection it ends up
> sending unencrypted data out over the socket, which doesn't work so
> well...


Further to this, I've made a small set of changes to how the Register_*
functions work so that the full connection struct can be tracked.

As hoped, this made it trivial to fix the handlers-cant-respond-over-SSL
bug from my last email.  Patch is available from :

    http://www.rfk.id.au:44445/


  Cheers,

     Ryan


-- 
Ryan Kelly
http://www.rfk.id.au  |  This message is digitally signed. Please visit
ryan@rfk.id.au        |  http://www.rfk.id.au/ramblings/gpg/ for details

On Thu, Feb 03, 2011 at 11:51:53AM +1100, Ryan Kelly wrote:
> On Wed, 2011-02-02 at 22:57 +1100, Ryan Kelly wrote:
> Further to this, I've made a small set of changes to how the Register_*
> functions work so that the full connection struct can be tracked.

This is great.  I totally forget why I didn't go the extra mile, but
this is a good fix.  Applied.

> As hoped, this made it trivial to fix the handlers-cant-respond-over-SSL
> bug from my last email.  Patch is available from :

You want commit rights on the main server?  Email me private and I'll
hook you up.

-- 
Zed A. Shaw
http://zedshaw.com/