Text 2921, 78 rader
Skriven 2008-04-06 13:09:01 av mark lewis (1:3634/12.0)
   Kommentar till text 2919 av Nick Andre (1:229/426)
Ärende: msgid
=============
> It MUST be unique. Sequential increment work fine until you somehow 
> reset the counter's value. Using time_t is much better, but there 
> could be messages sent with interval less than 1s between them. The 
> good solution used by most modern software utilises the sum of time_t 
> and some counter, which is reset at start. Manually composing a 
> message usually takes at least a minute, so this method works just 
> fine.
  
 NA> Thats how it works on D'Bridge except what I'm doing is using
 NA> fractional-seconds as well... just in case... even though the
 NA> internal message editor takes at least one second to respond via
 NA> the Reply command.

now consider an automated posting utility ;)

i've a lowly one that has been tested at 100+ messages per second...

the "formula" i use is one that leonard erickson posted years ago with a small
modification...

check the date on this yet /another/ message from NET_DEV...

[START QUOTE]
Area: FIDONet Developers Area (E)
Date : Apr 15 1994, 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]

)\/(ark

 * Origin:  (1:3634/12)