Connection API?

Maxim Dounin mdounin at
Mon Dec 3 19:06:13 UTC 2012


On Mon, Dec 03, 2012 at 06:37:56PM +0000, Nick Kew wrote:

> On Mon, 3 Dec 2012 21:31:52 +0400
> Maxim Dounin <mdounin at> wrote:
> > > Thanks for the reply.  You mean you're happy to add a new-connection
> > > hook, but not a context?
> > 
> > Something like this.  I would like to see use case first though, 
> > to make sure it indeed requires connection start hook.
> The basic use case is for a module that hooks in a library
> that needs to be notified of new connections.
> There are a couple of reasons for this.  One is that it has
> its own connection struct that needs to be initialised before
> it can process requests on the connection.  To do that
> per-request would require a lookup table of existing
> connections, and a mutex to prevent a race condition
> between requests on a connection.  In other words, quite
> a lot of extra complexity.

You don't need mutext as there are no threads.  And you don't need 
a lookup table at all as long a you'll follow already suggested 
way to store per-connection data.  That is, this part doesn't 
seems to be relevant.

> The other reason is, this is a security tool, and we'd like
> to know about any connections that are NOT followed by a
> valid (and notifiable) HTTP request, and might be part of
> an attack on a server.

This one looks better.

> > As of now its always true.  Note though, that with SPDY patches 
> > Valentin is working on it will likely change.  I've just talked to 
> > him and he suggests to compare r[12]->connection->fd instead as a 
> > more bulletproof solution.
> Surely an fd will be recycled/re-used?

Much like r[12]->connection, which is reused as well.  You 
never asked if r1->connection == r2->connection means r1 and r2 
are on the same connection, and obviously the answer is no.

> OK, I can work around that, too: just a little extra work to re-use
> the library's connection initialisation to generate a key.
> Though it means holding a mutex rather longer!

There is already r->connection->number which is incremented 
each time new connection is accepted, and it's highly unlikely 
that two distinct connections to have the same fd and number.

Maxim Dounin

More information about the nginx-devel mailing list