On 2007-08-31 11:28:55 -0400, m. allan noah wrote: > On 8/31/07, Peter J. Holzer <[EMAIL PROTECTED]> wrote: > > On 2007-08-31 10:42:37 -0400, Charlie Brady wrote: > > > 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?
When a client doesn't explicitely bind() to a socket before calling
connect(), the OS will choose a port number and IP address. The IP
address will generally be that of the interface that the connection goes
out of. If the server IP address is local, then the same IP address will
be chosen for the client. So, as a special case, if the server listens
on 127.0.0.1:25, any connection coming in on that port will be from
127.0.0.1:nnnnn.
> 2. why do we need a 'transaction ID' prior to a connection?
Don't think of it as a 'transaction ID'. Think of it as a 'logging ID',
which identifies the entity to which the log message belongs. There are
things which have to be logged before the first connection (e.g.,
problems with loading a plugin) and you want to identify where they come
from.
> 3. can we separate 'startup' type messages from transaction-based ones?
Probably. In logging/file_connection I used a "server instance id"
(startup timestamp + pid of the forkserver parent process) plus a simple
counter for the connections. Due to a quirk which I never investigated,
all the "startup" messages have a "connection count" of 2, the connections
start at 3. In an earlier message I suggested extra counters for the
transactions and possibly commands, so the full scheme could be
something like:
$instance_id # could be opaque or structured to include server name
# or IP, PID, etc.
$instance_id.$connection_id # identifies a connection handled
# by this instance
$instance_id.$connection_id.$transaction_id # identifies a
# transaction within
# this connection.
...
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | [EMAIL PROTECTED] |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
signature.asc
Description: Digital signature
