On Mon, Oct 21, 2002, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Mon, 21 Oct 2002, Johannes Erdfelt wrote: > > Perhaps I misunderstood. The patch I had developed (which is broken > > because of the problems with the accept lock) just didn't listen on the > > socket if it has no chance of answering the query itself. > > > > That's what I thought you meant, but reading what you said again I may > > have misunderstood. > > Nope, that's exactly what I meant. (see below) > > > Did you mean closing the client socket or the listening socket? Wouldn't > > closing the client socket just cause the client to treat it as an error? > > Just close the listening socket in the child_init phase of the > module. You want to do this before you start accepting requests. You > could also do this by just removing the socket from the accept array. The > reason I like having the child close the socket, is that it eliminates > a potential bad config. > > Consider the case where an admin configures the server to listen on > www.foo.com:8080, but he never assigns a child process to listen to that > port. If you just don't accept the connections, the user will hang > forever. If every child process, however, actively closes the sockets > that it can't serve, then the client won't even be able to connect.
That's a good point too. > > What I was thinking was to add an artificial limitation that you can't > > share an IP:port pair across two different uid/gid's since that's the > > only case you want to pass a connection. > > That limitation should already exist, although it may not. That limitation doesn't exist either in the documentation or in the implementation. I figured that was part of the point of connection passing. I know it's also useful for passing between the siblings for a particular uid/gid also, but why not just require 1 child per uid/gid and then not worry about connection passing at all? JE
