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