On 8/31/07, Peter J. Holzer <[EMAIL PROTECTED]> wrote: > On 2007-08-31 10:42:37 -0400, Charlie Brady wrote: > > > > On Fri, 31 Aug 2007, Michael Holzt wrote: > > > > >>You can't have multiple processes bound to the same > > >>local_IP/local_port, > > > > > >Of course you can. > > > > > >bind -> listen -> fork > > > > Yes, brain fart at my end. s/$/ except by inheritance post-fork/. > > > > If we stop listening post-fork (as qpsmtpd-forkserver does) then this > > state only occurs briefly. And since the fork occurs after accept(), then > > we already have a TCP four-tuple during that time interval. > > > > However, there is still an issue with Peter's proposed "zero out remote > > address components" proposal - prior to accept(), qpstmpd-forkserver may > > have multiple listening sockets. Some of those sockets (e.g. 127.0.0.1:25) > > won't be unique across multiple hosts. > > 127.0.0.1 is a problem even after establishing the connection: With > "normal" routing arrangements the remote IP address will be 127.0.0.1, > too, so the only variable is the remote port. If you aggregate log > messages from several hosts which receive locally generated messages, > that can be a problem. >
questions: 1. why would the remote ip be localhost once a tcp connection is established? 2. why do we need a 'transaction ID' prior to a connection? 3. can we separate 'startup' type messages from transaction-based ones? -- "The truth is an offense, but not a sin"
