Text 46, 92 rader
Skriven 2005-02-09 12:32:56 av mark lewis (1:3634/12)
     Kommentar till text 38 av Maurice Kinal (1:153/401.1)
Ärende: does anyone really care what time it is?
================================================
 MK> I figured out that it takes roughly 9 microseconds for this
 MK> computer to figure out what time it is at any given moment and
 MK> print that to whatever output.  That is a heck of alot of
 MK> unique microseconds within any given day.  However that one
 MK> piece of information alone will chew up most of the 32 bits
 MK> allocated to the second part of the MSGID which does nothing
 MK> to insure uniqueness over a long period of time - say three
 MK> years for arguement sake - especially if a user is dumping
 MK> text file(s) to be processed roughly the same time every day,
 MK> which isn't unrealistic.

 MK> I need more bytes!!!  :-)

in reality, no you don't... what you need to do is to not restrict yourself to
using the clock to generate the MSGID info... think about it... what happens if
your clock gets set back? ;)

if you want something that i've been using for years, you are welcome to it...
however, in total reality, all you need is a serial counter that gets
incremented each time it is used... what i use seperates the MSGID serial
number into sections for multinode operations and allows for each node to
generate some 8000 messages per day... my software only does 255 nodes so that
gives you an idea of the quantity of messages able to be generated... in
addition, there is a serial counter that is rewound each day as well as a
partial timedate...

in any case, a plain jane serial counter that your software increments is the
simplist and easiest... i never have figured out whay everyone wanted to (way
back when and still do today) jump on the clock counter...

===== quote =====

Area: FIDONet Developers Area (E)
Date : Apr 15 '94, 20:20
From : Leonard Erickson                                       1:105/51.0
To   : Paul Edwards
Subj : Re: EchoMail
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

 -=> Quoting Paul Edwards to Mikael Ståldal <=-

 PE> There is no requirement for there to be a MSGID kludge, and can you
 PE> honestly say that you have NEVER been at risk of violating the MSGID
 PE> standard, ie there was no possibility that you ever generated two
 PE> MSGID's the same within any 3 year period?  I certainly can't.

The identifier part of the MSGID is 8 hex digits. As a worst case,
there are 1096 days in 3 years. (assuming that there's aleap year in
there somewhere). There are 86400 seconds in a day. That gives 94694400
seconds. In HEX that's 5A4EC00. Note that this is *7* digits. The max
number of possible ID's is 100000000h. Doing the division gives 2Dh or
45d IDs for each second. I think we can live with a system that's
limited to tossing messages at 45/second. Or that tosses faster, but
won't let itself be run again until enough time has passed. 3.9
*million* messages per day is more traffic than anybody is likely to
generate!

As a *simple* method of doing this, have the program generate the
Julian Day Number (April 15, AD 1994 is JD#2449457). Then figure modulo
2048 of it. That's 49. Shift it to the right an appropriate number of
bits (multiply by 20 00 00 hex). That gives us 62 00 00 00 hex. And we
have 20 00 00 hex or 2,097,152 decimal message numbers per day. I think
that can be handled easily enough. Just generate a message number
(starting at 0 for the start of the day) and add it to the modified jd.

So we get:
        serial = (JD# mod $800) * $200000 + mnum

That's *not* that hard. And you can even allow for multiple tasks by
just allocated the least significant digit or digits. With 2 digits
allocated for a task number, that gives each task 8k numbers to
allocate per day. I think that's enough. :-)

For up to 16 tasks:
        serial = (JD# mod $800) * $200000 + num *16 +task #

For up to 256 tasks:
        serial = (JD# mod $800) * $200000 + num *256 +task #

.!. Unrecoverable Application Error: (A)bort, (R)etry, (B)uy Desqview ?
-!- Blue Wave/QBBS v2.12 [NR]
 ! Origin: Shadowshack (1:105/51.0)

===== end quote =====

in pascal, i implemented the above pretty much exactly as show... then someone
pointed out that psrt of the above could be switched around to be more linear
in the "look"... you'll note that a serial counter is still used, though ;)

)\/(ark

 * Origin: (1:3634/12)