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)