On Thu, 2007-08-30 at 10:45 +0200, Tony L. Svanstrom wrote: > > > Would this be a bad time to mention that people might get the idea that > > > they want to run two different setups of qpsmtpd on the same server? > > > > No that's fine. PID is still in there taking care of that. > > True, but the code makes both the security guy and the programmer in me > twitch...
rotfl > > The part of the unique ID meant to identify the server is now focusing on > the > OS/computer instead of the instance of qpsmtpd; which one can only get away > with as the PID is in the connection ID-part, and thus we shouldn't get more > collisions just because we run more than one instance on the same server. > > However, this is not only (currently) an undocumented and somewhat unobvious > feature of the ID-generation, but it's also an unnecessary limitation. > If people ever were to remove the PID, maybe as soon as at the end of this > discussion, they might not think about fixing the $SALT_HOST. wtf does this mean - the *purpose* of the discussion is to *fix* a *unique* transaction ID when the discussion is over it is *fixed* and the discussion *documents* the implementation. What do you mean "people ever were to remove the PID" ? If you make random changes to any piece of code it's going to break. > > Using the IPs + port ought to be the way to go. Please clarify. Given sufficient resolution in the time(), you cannot have two processes on the CPU for the same transaction ID. I thought there might be a problem if you have multiple CPUs but Peter H. has pointed out that the PIDs must be different in that case. You need to have context-switching faster than the clock resolution for collisions in time() -- Peter has shown that the clock resolution is (close to) 1 us for all likely systems other than the alpha. > -- --gh
