On 2019 May 19 02:27:00, you wrote to Andrew Leary:
AL>> The serial number may be any eight character hexadecimal number, as
AL>> long as it is unique - no two messages from a given system may have
AL>> the same serial number within a three years. The manner in which
AL>> this serial number is generated is left to the implementor.
DS> That sure sounds like the MSGID *must* guarantee no dupes.
yup... for three years...
AL>> For normal messaging use, using the Unix time as the base of your
AL>> MSGID serial number is adequate, unless you write messages very
AL>> quickly, ie: more than 1 per second. Autoposting of text files to
AL>> message bases for such things as online game scores, new file
AL>> announcements, etc. is usually where time-based MSGID serial number
AL>> generation breaks down.
DS> And so folks need to slow that process down. If I were in such a
DS> situation, I would use a batch/cmd file with a time delay between postings.
that's an option as is using a plain sequential serial number method... my
postit tool uses a combination of time, serial and BBS task number... each
night at midnight, the serial portion is restarted at zero... in fact, here's
the base proposal i started with...
==== 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-unix.txt" ====
)\/(ark
Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it
wrong...
... Do not protect yourself by a fence, but rather by your friends.
---
* Origin: (1:3634/12.73)
|
