Subj : I think this is the best
To   : Jame Clay
From : Maurice Kinal
Date : Thu Feb 10 2005 02:19 pm

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
 * Origin: Coffin Point - Ladysmith, BC Canada (1:153/401.1)

.