On Fri, 2007-08-24 at 13:18 -0700, James W. Abendschan wrote: > On Fri, 24 Aug 2007, Guy Hulbert wrote: > > > > These are the approaches suggested so far. I added the last one as a > > > combination of the others. Can we see a show of hands for the one > > > > Using rand is bogus. A random number generator will repeat values. > > > > Time (with sufficient resolution) is equivalent to a sequence ... but > > with threads, you would need a lock on the sequence generator. > > fqdn + time + peer TCP port will be pretty unique, regardless of
fqdn is the trivial part rand will be "pretty unique" ... time by itself is sufficient if the resolution is fine enough ... the problem is that when systems are "fast enough", whatever fixed resolution you picked will not be enough. However, at present the linux kernel gives microseconds (%.6f rather than %.4f) and it seems to take about .0001 seconds to fork a process so if forking, microseconds seem to be sufficient for a few years. ... but threads may be able to get the same value ... The problem with a sequence is to continue through a crash without repeating values. > whether you're forking, selecting, or threading. (fortunately, > multiplexed SMTP does not yet exist.) > > Looks like remote_port is set in qpsmtpd-forkserver, at least.. > > James > > > > -- --gh
