Hey Jame!

Feb 14 13:35 05, Jame Clay wrote to Maurice Kinal:

 JC>    What do they have over just tracking a number that keeps being 
 JC> incremented? 

Not much other then a base time/date which tells roughly when pkt creation
occured.  That tells something and could potentially be used to track down
problems, such as scanning a log file(s) looking for useful information
about that particular pkt given that most, if not all, log files use
time/date to log whatever it is they are keeping track of.  A straight
incremented number doesn't really yeild all that much information about
itself other then wrt other pkts.


 JC> That it's a function, which can be implemented in more than one 
 JC> place, rather than something like incrementing a number kept in a 
 JC> file... 

It's okay.  There is room for improvement though.

 JC> recently;  kept on coming back to the incrementing serial number kept 
 JC> in a file, for simplicities sake...

I may end up doing just that since some information is going to have to be
kept onhand for each client anyhow, such as their particular point number,
to ensure each one gets a unique ID even when the last part of the MSGID is
the same as another client's.  It could happen and this would help avoid
the entire MSGID being duped by differing clients.  I have no idea how that
might affect other's {up,down}stream but there is only so much any one of
us can do about this "standard" and making it at least half-assed
useable.  :-)

 JC>    Haven't had a chance to test it out (have to move again), but will 
 JC> when I
 JC> can.   

No rush here.  I've got some other distractions here as well.

Life is good,
Maurice

--- Msged/LNX 6.1.2