Connection API?

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


Hello!

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 mdounin.ru> 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
http://nginx.com/support.html



More information about the nginx-devel mailing list