Hey Jame!

A followup to the previous two messages about MSGID generation;

I like the idea of a meaningful bitfield that can be converted to hex the
best, and am going with the strategy of reserved bits.  From left to right,
3 bits for year (8 states), 9 bits for day of year (0 - 365 for leap year,
364 otherwise), 5 bits for hour (0-23), 6 bits for minute, and 6 bits for
second.  That leaves 3 bits for the <= 8 messages per pkt.  If a session
with any particular client contains more then 8 messages then whatever
multiple of 8 messages of pkt's can be created and the MSGID's of those
messages will be based on an incremented base pkt number off the first
created pkt in that session.  That way if it takes less then a second to
generate any of the pkts then it will avoid creating a duplicate pkt as
well as duplicate MSGIDs.  Does that make sense?  Thus the only time or
call to localtime is at the very start of the session and what follows is
based on that time and not any additional calls to localtime which can, and
most likely will, produce dupes that are not dupes.  Also this routine will
assure that all the messages within that particular session will generate
unique MSGIDs that can be later exploited for whatever reason and shouldn't
cause any duplicated MSGIDs for at least eight years.  The only way that
could happen is if the same client logs back into the system in less then a
second, or in less seconds then number of base pkt's created, so that the
base ID would be the same as one of the pkt's IDs of the initial session.

For argument's sake, let us suppose that the client dumped 40 messages in
the initial session.  That means 5 pkt's were created with the pkt ID's
incremented by one from the base pkt ID extracted from localtime at the
start of the session.  To successfully generate a new pkt with the same ID
as any of ones from the first session, the client would have to login and
start the function in less then 5 seconds from when it logged off.  On this
LAN that is impossible unless the clock stopped or hiccupped.  Also that
means that client either can edit new messages very fast OR is dumping
messages that have already been dumped OR messages that have nothing to do
with that same client.  This should trigger an alarm or flag of some sort
seeing as this client is more then likely up to no good.

What do you think?  Myself, I am warming up to it.

Life is good,
Maurice

--- Msged/LNX 6.1.2