REPLY: 1:275/362.0 5c9edd22   
   MSGID: 1:3634/12.73 5c9f8f1e   
   PID: GED+LNX 1.1.5-b20180707   
   CHRS: CP437 2   
   TZUTC: -0400   
   TID: hpt/lnx 1.9.0-cur 07-09-15   
      
    On 2019 Mar 29 22:06:18, you wrote to Maurice Kinal:   
      
    ON> it would make sense on the server to use timestamp - and a piece of   
    ON> logic to make sure no two nodes post during the same second.   
      
   i would not rely on seconds granularity at all... sure, for manual posting but   
   certainly not for offline QWK/QWKE/BW uploads where the user may upload 50+   
   messages in one go... are you going to make them wait for 50 seconds while you   
   delay a second for each message? what happens if you have two or more users   
   online which upload their offline replies at the same time? sure, the odds are   
   against that happening but we all know the name of Murphy very well, don't we   
   )   
      
   then there's external automated posting tools that can easily post 100+   
   messages per second on today's hardware...   
      
   using the timestamp along with a plain simple serial number would work... but   
   for that matter just a plain simple serial number is really all that is   
   needed... i never did figure out why so many tried to come up with convoluted   
   serial number generating routines... i remember that many used CRC16 and then   
   CRC32 which are well known to have limited range as well as easily hit   
   collisions... then some thought of using MD5 which then had to be chopped to   
   fit within the limits of the serial number and again, limited range and   
   collisions reared their heads...   
      
   but i know of at least one format, written in 1994 and implemented that same   
   year, that incorporates the multinode node number, timestamp and serial   
   number...   
      
   ==== Begin "MSGID.TXT"  ====   
   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 "MSGID.TXT" ====   
      
   the above may not be sufficient, though, if one is importing usenet newsgroups   
   and generating MSGID serial numbers for them... however, the idea is quite   
   workable...   
      
   i have pascal code that does the above with some slight variation and at least   
   two FTN capable programs are using my code under license but it is still   
   simple enough to create and manage... it was testing on a live system for just   
   over three years before being released for public consumption in utility   
   tools...   
      
   the only real gotcha is if the incremental serial number file is lost... then   
   it may be possible to generate duplicate serial numbers on the same day from   
   the same node but once the date rolls over, that is taken care of... unless   
   the system clock gets reset for some reason... ok, so that's two possible   
   gotchas...   
      
   either way, plain straight incremented numbers are the easiest and you don't   
   need to worry about the clock or how many nodes... just that the serial number   
   file is not reset... of course proper file locking and access is needed to   
   protect against two or more nodes getting the same number at the same time...   
      
   so anyway, there it is, FWIW...   
      
   )\/(ark   
      
   Always Mount a Scratch Monkey   
   Do you manage your own servers? If you are not running an IDS/IPS yer doin' it   
   wrong...   
   ... Too many people think a potato tastes like a Pringle.   
   ---   
    * Origin:  (1:3634/12.73)   
   SEEN-BY: 1/120 15/2 18/0 200 116/116 123/0 25 50 150 755 1970 135/300   
   SEEN-BY: 153/7001 7715 154/10 20 30 40 700 203/0 221/0 6 226/17 227/400   
   SEEN-BY: 229/107 354 426 452 1014 240/5832 249/206 317 400 261/38   
   SEEN-BY: 280/464 5003 310/31 317/3 322/757 340/800 342/200 393/68   
   SEEN-BY: 396/45 423/120 633/280 770/1 3634/0 12 15 27 50   
   PATH: 3634/12 154/10 280/464 229/426