Subj : talking to myself To : Maurice Kinal From : mark lewis Date : Sun Feb 13 2005 02:10 pm RT>> A MSGID is a valued item here, especially when it comes to dupe RT>> checking, so RT>> if you are able to generate them fast enough, then please do so. MK> Generating them fast isn't a big issue but making them MK> meaningful is a tad tricky given the accepted "standard", if I MK> can be so bold as to call it a "standard". they aren't supposed to be meaningful... they're just a serial number assigned to a message, for diety's sake... MK> If based on time and/or date (is there a difference?) then it MK> slows things down and given the current limitation makes it MK> even trickier and slower. That is why I thought a base ID at MK> the start and incrementation within a loop for multiple MK> messages might be a better objective as it wouldn't add any MK> extra calls and is faster then calling localtime for each one, MK> which will produce dupes that aren't dupes if limited to MK> seconds on a fast machine. This way it won't matter even if MK> the machine is slow enough to produce unique IDs using MK> seconds. This method does speed things up and should produce MK> unique IDs for whatever length of years as bits allocated to MK> the "year" employed. you're still looking too deeply... why go thru all that when you can seed a counter at 0 (zero) and increment until it hits 2147483647 and then roll it and start over at 0 (zero) again... based on 365 days in a year, three years is 1095 days... dividing, that gives us 1961172 messages per day... surely that's enough and the method easy enough??? the "problem" is storing the serial counter... another "problem" is that even with non-duped MSGID serial numbers, it is possible for some software to see a false-dupe... they do this because they aren't always looking at the MSGID but only at the header of the message... some of them will go a tad further by looking at the header plus some (maybe 30 or 40) additional bytes to try to see if the message body is different... for this reason, i place the MSGID immediately after the end of the message header and all other control lines then follow that... for some reason, i'm also thinking that the message headers that contain seconds are stuck with a 2 second granularity in the same vein that billy's file systems have been from the beginning... however, i've not the time nor inclination to go rooting thru the archives to confirm this "memory"... )\/(ark * Origin: (1:3634/12) .