Text 59, 44 rader
Skriven 2005-02-10 14:19:32 av Maurice Kinal (1:153/401.1)
     Kommentar till en text av Jame Clay
Ärende: I think this is the best
================================
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)