On Thu, 30 Aug 2007 the voices made Guy Hulbert write:
GH> wtf does this mean - the *purpose* of the discussion is to *fix* a
GH> *unique* transaction ID when the discussion is over it is *fixed* and
GH> the discussion *documents* the implementation.
I meant undocumented as in it in Transaction.pm currently says "Generate
unique id" without mentioning that the earlier defined $SALT_HOST relies on
certain aspects of the ID-generation, without which the $id might not be unique
in cases where there's more than one instance of qpsmtpd running on a single
server. (Or on two different servers with the same hostname, which isn't
exactly unheard of; it happens both by mistake and by design, for instance if
setting up a testserver... which you still might want to use with whatever
centralized logging you've got.)
GH> What do you mean "people ever were to remove the PID" ? If you make
GH> random changes to any piece of code it's going to break.
Random changes yes, but as this discussion has clearly shown it isn't
unreasonable to consider creating unique IDs without using the PID
(incrementing counter etc); and it isn't unreasonable to view the transaction
ID and the server ID as two seperate things, which combined creates a
(hopefully) universally unique ID. Even the (current) code structure reflects
such thinking.
To then use a server ID that I think everyone on this list can agree on has a
lesser chance of being unique, esp. if minor changes are made to it, isn't as
future/idiot-proof as it easily could be; and if it's easily done at least I
prefer to write code that minimizes the chances that people will mess up when
working with it.
It's enough that someone removes the crypt+rand to easier search the logs for
this solution (hostname-based) to theoretically start creating trouble/break
(well, at least crack slightly in a corner or two).
GH> > Using the IPs + port ought to be the way to go.
GH>
GH> Please clarify.
To qpsmtpd the hostname isn't as unique as the IPs + port used by it is.
Actually, although IPs+port IMHO is better than hostname it was silly of me to
say that it "ought to be the way to go", as it doesn't deal with special-use
addresses well enough... but it'd be easy to catch those and do something
create/output a warning.
I think I'll exit the discussion here; you can battle it out among yourselves,
and if I'm unhappy with the results I'll just show up with some code and
restart the fire... ;-)
GH> Given sufficient resolution in the time(), you cannot have two processes
GH> on the CPU for the same transaction ID. I thought there might be a
GH> problem if you have multiple CPUs but Peter H. has pointed out that the
GH> PIDs must be different in that case.
GH>
GH> You need to have context-switching faster than the clock resolution for
GH> collisions in time() -- Peter has shown that the clock resolution is
GH> (close to) 1 us for all likely systems other than the alpha.
Or the same hostname on a second server, which is something we shouldn't rule
out...
/Tony
--
"Generally speaking, taunting mentally unstable people is a bad idea."
