On Mon, 21 Oct 2002, Johannes Erdfelt wrote: > On Mon, Oct 21, 2002, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > 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? > > > > A couple of reasons. Remember first of all that the more threads per > > process, the less stable your server. This is because if a module > > seg-faults, the whole process dies. For that reason, many admins will > > want to have multiple child processes with the same uid/gid to create some > > failover. > > > > The second reason, however, is that the file descriptor passing is meant > > to solve the case of multiple Name-based Vhosts on the same ip:port all > > with different uid/gid requirements. In that case, you will have multiple > > child processes all listening to the same ip:port, but you will need to do > > the file descriptor passing. > > Well, that's what I said before, but you implied that the limitations > should prevent this. :)
yeah, you're right, I wasn't thinking when I wrote that. Sorry. > > Closing the file descriptors of ip:port combinations that can't be served > > is a great optimization, but that is all it is, an optimization for the > > non-Name-based vhost case. > > Yes. > > This brings it back to what I was saying before, you can't pass SSL > connections, so as a result, you can't share an SSL port across two > uid/gid's. So this should be documented somewhere, or enforced in the > server (which may be difficult because of the layering), so people don't > do that :) You don't need that doc. In order to share an ip:port combination across child processes, you need to be using name-based vhosts. SSL doesn't support name-based vhosts today, so there is no new docs required. Of course, if my patch to provide Upgrade support goes in, then you will be able to share ip:port combinations that support SSL across child processes. So, the docs really aren't necessary. > Anyway, I think I understand the path to follow now. I'm going to > implement the necessary fixes to make perchild finally usable. Great! Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------
