On Thu, 2007-08-30 at 10:30 -0400, Matt Sergeant wrote: > On 30-Aug-07, at 10:07 AM, Tony L. Svanstrom wrote: > > > On Thu, 30 Aug 2007 the voices made Guy Hulbert write: [snip] > > GH> the discussion *documents* the implementation. > > > > I meant undocumented as in it in Transaction.pm currently says
In principle, the documentation will be updated when the discussion is complete. > > > "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. > > Including PID takes care of that. And you're assuming a broken srand > () too. > > Admittedly, there's a very very remote freak possibility that given > two identical hostnames, a rand() with a broken srand(), and those > servers starting at the exact same microsecond time with the exact > same PID, that you MIGHT, just MAYBE, get a duplicate transaction id. Nope. I reject this. The design ASSUMES that the clock has "sufficient resolution". It is the implementation which chooses Time::HiRes. There are two "perfect" solutions (bikesheds ;-): 1. Use a timer based directly on the values in the instruction count register. IIRC, the linux kernel clock (at least on intel) just quantizes this in either micro- or nano- seconds. [bikeshed = kernel patch] 2. Implement our own "clock" using a sequence generator, which reads the last value out of the tail of the log on startup (and is thread/async-safe). I think that using PID is a bit of a hack but it seems to work in every case that anyone has come up with. It should be changed to TID, should qpsmtpd ever be blessed as "thread-safe" but I'm not holding my breath for that to happen ;-) ... besides, async is a much better choice (compare lighttpd with apache). > > The alternative seems to me the only way to satisfy your security > paranoid mind is to use Data::UUID, which is an extra dependency I I think the use of the adjective "security" in this context is rather generous. > > don't want to add in. > > Matt. -- --gh
