On 2007-08-31 17:28:26 +0000, Matt Sergeant wrote: > On Thu, 30 Aug 2007 [EMAIL PROTECTED] wrote: > > >Modified: > > trunk/lib/Qpsmtpd/Connection.pm > > trunk/qpsmtpd-forkserver > > > >Log: > >Connection id similar to the transaction id by Matt. > > For what it's worth I really don't like this implementation -
Neither do I - I added it mostly to show the difference between
connection and transaction ids. To avoid confusing the issue with other
changes I just reused your implementation.
> if we're going to add in a connection id it should be identical to the
> transaction id, but with a counter added.
You mean the other way around, don't you? A connection can consist of
many transactions, but each transaction can only belong to one
connection. So a transaction id would be a connection id with a counter
added.
> Currently this will give a different "host" part to the transaction
> id, which just seems wrong to me.
That's because of the random salt. I don't like that much, either.
In fact I rather like Charly Brady's idea of using local and remote ip
addresses and port numbers except for the problems which I already
mentioned on the list. But I see no way around these problems, so I'm
not pursuing this further.
So, what do we want and what do we have?
What we want:
A way to identify an "instance" of qpsmtpd. That includes the host, and
at least the process.
Within each instance we want to identify the connection, if any.
Within each connection we may want to identify the transaction (I'm not
so sure we need this).
What we have:
A Qpsmtpd object. I think such an object identifies an "instance": with
qpsmtpd this is trivial, qpsmtpd-forkserver creates one such object in
the parent which is inherited by the children, -async creates one per
process and with Apache::Qpsmtpd I'm not sure: One per perl-interpreter
I think, which may mean several per process with a threaded worker.
I think we can identify such a Qpsmtpd object with a host id (IP
address, (hashed) hostname, MAC address ...), creation timestamp and
pid. So this is basically your transaction id, except that I omitted
your sequence (we have generally only one Qpsmtpd object per process, so
the sequence would always be 0), and I think I prefer a predictable host
id.
A Qpsmtpd::Connection object which identifies a connection (although
such objects can also be created without a connection).
This would be uniquely identified by the id of its parent Qpsmtpd object
plus a simple counter. Instead of a counter, other information could be
used, but any other unique information would be a lot bulkier.
A Qpsmtpd::Transaction object which identifies a transaction (although
such objects can also be created without a transaction - for example,
when a logging plugin is called, which typically first happens during
load_plugins). This can be implemented as the connection id plus a
counter.
We have the problem that there is no easy way to get from the
transaction to the connection or from the connection to the qpsmtpd
object, but it turns out we don't actually need them. The connection
counter needs to be in the qpsmtpd object anyway, and keeping the
transaction counter there, too is consistent with reset_transaction
being a method of the qpsmtpd object.
I have implemented this now. As the host id I have just used the
first ip address of the host. This is simple, predictable and should
work in most situations. Where is doesn't, a logging plugin could
override the id() method of Qpsmtpd::SMTP.
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
