Text 1059, 106 rader
Skriven 2012-07-21 23:28:56 av Rob Swindell (138629.fidonews)
    Kommentar till text 678 av mark lewis (1:3634/12.0)
Ärende: MSG-IDs
===============
  Re: .fidonet
  By: mark lewis to Nicholas Boel on Mon Jul 16 2012 12:20 pm

Repost:

 > MSGID and REPLY not being used
 > completely properly anyway... witness any synchronet reply to one of your
 > messages that has no MSGID in it and you will see a bogus REPLY line...

I already debunked this claim, but since I see it again here (in an older
message), do you care to site any specific examples of this ficticious
behavior? Or are you ready to admit that your claim was false?

 >  NB> They're expecting a MSGID that looks like "1:103/705 89348af" but
 >  NB> that is simply not enough unique information to create a
 >  NB> system-wide unique message ID, and it's a well known problem the
 >  NB> FTS-9 MSGID format, and different folks have worked around it in
 >  NB> different ways, some have just ignored the problem.
 >
 > bullshit... it is enough for a system wide unique format... one only really
 > needs a sequential serial number routine that starts at 00000000 and counts
 > up to ffffffff before starting over again and not repeating within three
 > years...
 >
 > otherwise you are trying to tell us that 4294967295 messages originating on
 > one system over three years is too small a number?? 4BILLION original
 > messages from one system in 3 years is not enough?!? only 1431655765
 > messages per year? 1.4BILLION messages PER YEAR is not enough of a serial
 > number counter??? on the one hand, i'd like some of that stuff you're
 > smoking plus a few snorts of that which you are drinking but on the other
 > hand, maybe not... not if is screws up the mental math like this...

The problems with the 32-bit serial number idea expressed in FTS-9 are widely
understood (and were discussed at length when I was a member of the FTSC
several years ago). You don't appear to be familiar with them, so I'll explain
them to you:

A system-wide message serial number scheme is not practical. Take your system
as a good example: When you post messages from your system via GoldEd+, your
messages' MSG-ID values look like the following:

        "1:3634/12.0 00834ed1"
        "1:3634/12.0 00834ed2"
        "1:3634/12.0 00834ed5"
        "1:3634/12.0 00834eda"
        "1:3634/12.0 00834edd"
        "1:3634/12.0 00896e10"
        "1:3634/12.0 00896e13"

Yet, when messages are posted from your system via your BBS (Remote Access,
using either RAEdit or the internal line editor), your messages' MSG-ID values
look like the following:

        "1:3634/12 4fef9508"
        "1:3634/12 4fef9620"
        "1:3634/12 50045268"
        "1:3634/12 50045c86"
        "1:3634/12 50070360"
        "1:3634/12 50073650"
        "1:3634/12 50079306"

(the above examples taken from recent messages from your system in this echo).

From this small sample, it is obvious that your BBS software and your sysop
message editor (GoldEd+) do not agree on the serial number generation scheme.
It is also obvious that your BBS software is using the current date/time value
(in Unix time_t format) as its "unique" serial number scheme:

time_t   1342673670  (0x50079306)    ISO 2012-07-18 21:54:30.000-07:00

This means that if 2 different messages were posted to your BBS within the same
second (e.g. 2 different users posting messages simultaneously on different BBS
"nodes"), the resulting non-unique messages would likely have the same serial
number. Obviously, using the current date/time is a broken method of serial
number generation; you should get that fixed for the good of the network.

Combine that problem with the fact that the GoldEd+ MSG-ID serial number scheme
is completely arbitrary and disconnected from your BBS software, and you have
another potential cause for 2 differnet messages from your BBS having the same
"serial number" (one being posted via your BBS using the current date/time for
the serial number and the other being posted via GoldEd+ and using whatever
scheme you have chosen for seeding its sequential serial number generation
scheme).

It's impractical to assume that *every* piece of software that is capable of
posting messages to FidoNet and is in use on a system will share the same
scheme or database of MSG-ID serial number generation. For this reason (and the
fact that 2 different systems can clearly have the same serial number for any 2
given messages), the *entire* MSG-ID value (not just the serial number field)
must be used to detect duplicate messages and provide reply-linking (and
threading). And since the "address of the originating system" would obviously
be the same (except in your case where GoldEd+ is adding the unnecessary ".0"
point but your BBS is not), more unique data is needed in the MSG-ID value to
guarantee system-wide unique MSG-IDs. This is the problem that the IETF and the
Synchronet developers have solved but your BBS software and message editor of
choice have not: no 2 FidoNet messages from any single Synchronet system can
have the same MSG-ID value, even if posted from multiple programs within the
same second.

                                            digital man

Synchronet "Real Fact" #72:
SyncTERM (created by Deuce) contains portions of Synchronet and SEXYZ code.
Norco, CA WX: 68.4øF, 73.0% humidity, 2 mph NW wind, 0.00 inches rain/24hrs
--- SBBSecho 2.13-Win32
 * Origin: Vertrauen - vert.synchro.net (1:103/705)