Here is an official test of duplicate MSGID serial numbers from two different addresses to see if it shows up as a false dupe..
My system has both of these
[1] == MID: 1:153/7001 8QIOgQad
[2] == MID: 1:153/7001.2989 8QIOgQad
Perhaps you need to keep the "address" part the same for a valid
test.
Perfect! That confirms that the address is indeed part of
the dupe checking routine.
[1] == MID: 1:153/7001 8QIOgQad
[2] == MID: 1:153/7001.2989 8QIOgQad
That is what I see here. Also there is no doubt they are
completely different MSGs, from two different systems.
Right? Also it appears from this angle that your idea for
the random serial number is indeed compliant with fts-
0009.001 despite objections anyone might have about the
methodolgy.
..I'll follow up this reply of a totally new MSG with the
"1:153/7001 8QIOgQad" address serial number. Don't touch
that dial!
And.. if I don't see it, it probably means it was detected as a
dupe along the way!
That is what I see here. Also there is no doubt they are
completely different MSGs, from two different systems.
Right? Also it appears from this angle that your idea for
the random serial number is indeed compliant with fts-
0009.001 despite objections anyone might have about the
methodolgy.
That little word "may" in the salient paragraph of the spec
opens up the possibilities.
And.. if I don't see it, it probably means it was detected as a
dupe along the way!
Yes. My money is on 1:153/757 since that system is the first that MSGs from 1:153/7001 will encounter. For sure the Europoint didn't see it so somewhere along the line it got caught as a dupe ... which of course it wasn't. It was a perfectly valid and original packed MSG with a duped MSGID which could happen although like you pointed out is highly unlikely to happen in a three year period.
@MSGID: 1:153/7001 8QIOgQad
@MSGID: 1:153/7001.2989 8QIOgQad
For the record we repeated the test on a local echoarea that all
concerned have access to and it 'failed' again which is exactly what
was suspected. Therefore we all concluded that dupe checking is ONLY
based on MSGIDs given all were original and compliant MSGs.
If you want I could repeat the third test here just to see how far your dupe checking goes when encountering a duped MSGID. I think it was worthwhile. Also the EuroPoint uses the 32-bit hex unixtime for it's serial numbers instead of the random 8 character [:alnum:] regex one but that shouldn't matter. What will matter is your dupe checker's abilities to differentiate between a real dupe and one where only the MSGID is duped.
Let me know and I'll make it so.
So if they differ, while the MSGID is the same it's not
considered a dupe.
You are welcome to test it, but I already know how it works.
Well FMail's dupe checking works a little bit different.
When there is a valid MSGID, it also uses the first
letters of the From, To and Subject, for it's dupe
checking. So if they differ, while the MSGID is the same
it's not considered a dupe.
Is that a way to reduce the probability of collisions within a
certain span of allotted time?
So if they differ, while the MSGID is the same it's not
considered a dupe.
Until it reaches one of your downstream links that isn't using FMail.
Well FMail's dupe checking works a little bit different.
When there is a valid MSGID, it also uses the first
letters of the From, To and Subject, for it's dupe
checking. So if they differ, while the MSGID is the same
it's not considered a dupe.
Clever, that is!
Is that a way to reduce the probability of collisions within a
certain span of allotted time?
Is that a way to reduce the probability of collisions within a
certain span of allotted time?
Good question. I've heard of a few different methods for doing this none of which I am currently deploying. Mind you I take care of MSGIDs in the creation of the MSG so the possiblity of collisions is near zero. There is
a way but if that happens then it is a signal that something is seriously wrong on my system. It has yet to happen.
Just for fun here is the output of 10 potential MSGID serailno's, the first
column being unixtime 32-bit hex based, the second being the random 8 character [:alnum:] regex dealies;
60760e0b kUBdI5RO
60760e0b G5T1LBae
60760e0b mFSS1Gxc
60760e0b Daxpq9EE
60760e0b XVCgstYj
60760e0b uWuB7Jqj
60760e0b J0qZbQIo
60760e0b kGrnLcEZ
60760e0b NQGnXOVM
60760e0b kK7htVJO
Note that only one method produced zero collisions while the other produced
nothing but collisions. Based on this very simple test the random 8 character [:alnum:] regex thingies are obviously superior.
... and only uses the MSGID for dupe checking...
So your algorithm based on unixtime has a bug!
It should take into account it can be called multiple times
within the same second.
If you do that correctly, it's superior to the random one...
Just for fun here is the output of 10 potential MSGID serailno's, the first column being unixtime 32-bit hex based, the second being the random 8 character [:alnum:] regex dealies;
60760e0b kUBdI5RO
60760e0b G5T1LBae
60760e0b mFSS1Gxc
60760e0b Daxpq9EE
60760e0b XVCgstYj
60760e0b uWuB7Jqj
60760e0b J0qZbQIo
60760e0b kGrnLcEZ
60760e0b NQGnXOVM
60760e0b kK7htVJO
I thought you said that your 32bit algorithm for the time-
version took into account fractions of a second down to the microsecond/nanosecond.
... and only uses the MSGID for dupe checking...
Yes. It only takes one in a strategic position to spoil it for everyone and you will never be aware of it until someone like me comes along to point out the obvious ... which of course everyone will ignore and do nothing about it. It happens all the time and not just in fidonet.
It should take into account it can be called multiple times
within the same second.
Sure. How about this?
6076da69-1689a348
6076da69-16bf0244
...
If you do that correctly, it's superior to the random one...
See above but just for fun I will do it side by side just like before.
6076e0bd-22d50e70 n3yM8uFm
6076e0bd-246302d4 sL4Irxdg
6076e0bd-25d0d1f0 8fq4vU7e
6076e0bd-276236a4 Aez4QZog
6076e0bd-28f6291c jbQiqKYc
6076e0bd-2a842704 gElrH3UT
6076e0bd-2bf24d98 8qmyLLQR
6076e0bd-2d8103dc Pbeaul1Z
6076e0bd-2f0436d0 IHsKacHr
6076e0bd-30a01b60 0An6jRkx
My best guesstimation is that the random one is superior given that it doesn't require a rewrite of current FTN standards.
However I do plan to change that and then for sure the unixtime based
one will be superior and unique for all time, nevermind 3 lousy years.
@MSGID: 1:153/7001 tmCYOYVw
Please note the MSGID of this reply.
It's not really a problem. Because collisions in the MSGID
seldom happen...
It doesn't conform to the standard.
It doesn't conform to the standard either...
I suggest you don't waist your time on fighting to get the
existing standard changed. It's wasted energy.
And thus heating up the planet more than a standard conforming
MSGID. :-(
I recall saying that your idea is superior since it doesn't
require any changes to existing documentation regarding
MSGIDs.
If I gave you the wrong impression I will now apologize for
my lousy communication skills. I am obviously a lousy
technical writer but in my defence I never claimed to be
good at it.
..Once 2106 rears it's ugly head there is nothing in my
routine that will prevent it from adding an extra hex
character but then it won't be compliant to the current
documented MSGID/REPLY format.
However the routine based on random 8 character [:alnum:]
regex should still be good to go if indeed my attempt at
forwards compatibilty fails, which according to everyone is
the most likely result.
I am on record saying that I am prepared to soldier on if
indeed that happens. That won't stop me from trying again
in the future but I cannot guarentee how long I can keep
soldiering on. I am getting old.
@MSGID: 1:153/7001 tmCYOYVw
Please note the MSGID of this reply.
Besides not conforming to the standard, and maybe cosing
problems in software down the line...
Because it doesn't conform to the standard (not strictly
hex chars),
my tosser uses a different method for calculating a hash
for this message (for dupe detection), which uses more cpu
cycles. And thus heating up the planet more than a
standard conforming MSGID. :-(
If you want a better unique identifier in ftn messages,
create a new kludge (see my suggestion for the @UUID one,
which needs a @RUID btw for replies), so you can do what
you want, and make it as good as possible without having
to consider existing software. Then write a proposal and
convince software developers to implement it in their
software.
..So far the only issue I have seen is on one particular
point software that buggers up the REPLY kludge but has no
effect on what really matters.
Speaking of nonconformity and obsolesence what is the deal with your
bogus CHRS kludge? -> "CHRS: UTF-8 2"
I suggest you don't waist your time on fighting to get
the existing standard changed. It's wasted energy.
Again I disagree. Nothing ventured, nothing gained. We'll
see but even if it fails I already feel like a winner and
have for around 20 years. Now I am just looking to share
the love. :::evil grin:::
But I think you are confusing the MSGID genererating side
and the dupe detecting on the other side of the fence. ;)
The MSGID generating side must try to prevent collisions.
The dupe detecting side can only respond to it by making
the detecting algorithm as robust as possible.
The ftsc write-ups could serve as a guidebook for solutions and
examples and help remove ambiguity and false interpretations.
Even 2038 maybe of little concern for most of here right now. :(
Yes.. it is sad that there is not much new or alternative
emerging in the "ideas" department for FTN.
I do hope to see what transpires commencing 2038.
Denis (using Winpoint) hasn't been seen lately. Maybe something
got buggered up badly?
That's telling him!
It's not really a problem. Because collisions in the MSGID
seldom happen...
How would you know? If you are only referring to your software of choice then the above might be true, especially if it is a single user application
which is common these days.
It doesn't conform to the standard.
Understood. Not a big deal as it could easily become redundant and unneeded once a real standard is in place that doesn't require ANY kludges.
It doesn't conform to the standard either...
I believe you are wrong about that but then again you're spin on it might have validity simply because of obsolesence. So far the only issue I have seen is on one particular point software that buggers up the REPLY kludge but has no effect on what really matters.
Speaking of nonconformity and obsolesence what is the deal with your
bogus CHRS kludge? -> "CHRS: UTF-8 2"
It might make someone question your credibilty on mattters of
conformance to "standards". Not me of course but then I am not that
anal when it comes to conformance to phoney-baloney kludges.
@MSGID: 1:153/7001 tmCYOYVw
Please note the MSGID of this reply.
Besides not conforming to the standard, and maybe cosing
problems in software down the line...
It seems to be a problem for WinPoint when building a reply
message. The REPLYID seems to result in 00000000.
Because it doesn't conform to the standard (not strictly
hex chars),
You are adding words to the spec. "strictly" does not appear.
;) However, "may" is very clear. :D
my tosser uses a different method for calculating a hash
for this message (for dupe detection), which uses more cpu
cycles. And thus heating up the planet more than a
standard conforming MSGID. :-(
They're all just a bunch of 1's and 0's in the end. It's all
the same stuff. :D
If you want a better unique identifier in ftn messages,
create a new kludge (see my suggestion for the @UUID one,
which needs a @RUID btw for replies), so you can do what
you want, and make it as good as possible without having
to consider existing software. Then write a proposal and
convince software developers to implement it in their
software.
So, are kludges like the wild wild west where anything goes?
That *is* a handy way to extend functionality and features.
It seems to be a problem for WinPoint when building a
reply message. The REPLYID seems to result in 00000000.
So that is the first discovered problem. There are
probably more. And probably harder to discover...
Because it doesn't conform to the standard (not strictly
hex chars),
You are adding words to the spec. "strictly" does not appear.
;) However, "may" is very clear. :D
I beg to differ...
They're all just a bunch of 1's and 0's in the end. It's
all the same stuff. :D
But how we get there isn't...
;) However, "may" is very clear. :D
I beg to differ...
According to fta-1006, the definitions are clear. But
interestingly, the doc expired 20 years ago. Why a definition
doc needs to expire (and not be replaced by something else)
alludes me.
They're all just a bunch of 1's and 0's in the end. It's
all the same stuff. :D
But how we get there isn't...
Oh.. that's true enough. But I've made my point. Assuming that
the serialno must be implemenet in hex is just that, an
assumption.
I think I red somewhere that every ftsc document needs to be
reviewed every 2 years
Well if most software expects a hex number, maybe the standard
needs to be reviewed, and worded more strict. ;)
Well if most software expects a hex number, maybe the standard
needs to be reviewed, and worded more strict. ;)
Or not. As is I think it is clear enough but a review of all standards is a good idea including MSGID/REPLY.
To review if they still describe current practice,
or could be worded better, not to change them to something
incompatible with current practice. ;)
..as well as the only user of an
official point system,...
official point system,...
What system is that?
Yet you viciously mention it...
Yet you viciously mention it...
I call that therapy.
I call that therapy.
For whom? You, or Wilfred? :D
The ftsc write-ups could serve as a guidebook for
solutions and examples and help remove ambiguity and false
interpretations.
FTA-1006 might be of interest to you wrt the subject at hand.
But even that one "expired" twenty years ago. :( So.. is it
valid today or not? :/
As valid as any of the other ones. I think if
there is a bone to pick with any document the
FTSC_PUBLIC echo would be the place to start.
Speaking for myself (all three of me) this
conversation in this particular echoarea was a
very good warmup for what could transpire if
anyone were seriously considering a needed
change. I still believe it could happen.
I have highlighted a few clerical flubs in the recent past in
there.
and 10 people at the helm
The nodal me thinks we have bigger fish to fry.^^^^^^^^^^^^^^^^^^
and 10 people at the helm
There's a helm?!?!?!?!
^^^^^^^^^^^^^^^^^^The nodal me thinks we have bigger fish to fry.
and 10 people at the helm
There's a helm?!?!?!?!
Ok.. kitchen. Cooks in the kitchen. And only because you
mentioned nodals (sic), noodles.
^^^^^ ^^^^^^^^^^^^^^^^^^The nodal me thinks we have bigger fish to fry.
and 10 people at the helm
There's a helm?!?!?!?!
Ok.. kitchen. Cooks in the kitchen. And only because you
mentioned nodals (sic), noodles.
I think rice goes better with fish.
Ok. The menu of savoury delights exists: FTS-XXXX, FTP-XXXX
..now get er done! <g>
I've been rethinking the rfc-3339 idea. Also spring
cleaning (the weather has been fantastic the last week) and
the second in the series of three x86_64-motorshed-linux-
gnu upgrades. Maybe by the end of the week.
Is there any item of interest to you?
This is my view as I take a glance above the laptop.
Not sure. It seems that you have some fine priority ideas.
This is my view as I take a glance above the laptop.
That is a nice view, other than the window that is. ;-)
(YYYY-MM-DD hh:mm:ss(+|-)utc_offset). If the
(+|-)utc_offset is dropped then the remainder fits in
EXACTLY in the field specified..
My personal favorite is the hex output of unixtime seconds-
nanoseconds but moreso as a unique serialno such as used in
MSGID/REPLY kludges. However I personally don't want to
screw with that particular document especially considering
how embedded it has become in fidonet MSGing.
But I might tackle the one in the picture - before the
blackflies emerge.
Whatever direction you take, feel free to announce any advances
and progress in FUTURE4FIDO (F4F).
-={ 2021-04-18 14:03:26.305578442+00:00 }=-
Hey August!
^^^^^^^^^^^^^^^^^^The nodal me thinks we have bigger fish to fry.
and 10 people at the helm
There's a helm?!?!?!?!
Ok.. kitchen. Cooks in the kitchen. And only because you
mentioned nodals (sic), noodles.
I think rice goes better with fish.
Life is good,
Maurice
... Wel mon sceal wine healdan on wega gehwylcum.
One does well to keep a friend on every road.
If fish is the primary item, then yes.
If it is secondary, it may be added to a noodle bowl.
-={ 2021-04-25 14:21:39.573006446+00:00 }=-
Hey Carol!
If fish is the primary item, then yes.
It is a very big fish which in itself makes it primary.
If it is secondary, it may be added to a noodle bowl.
Speaking for myself, I think pork goes best with noodles.
Life is good,
Maurice
... Heald hordlocan, hyge fæste bind mid modsefan.
Hold close the treasure-chest, bind your thoughts fast within the heart.
Both go well with noodle bowls!
It seems to be a problem for WinPoint when building a
reply message. The REPLYID seems to result in 00000000.
So that is the first discovered problem. There are probably more. And
probably harder to discover...
I may have to spin up my Winpoint to see for myself. But apparently Winpoint is getting new life in development and the
uber msgid could be accomodated. :D
AREA:ASIAN_LINK
@RESCANNED 2:240/1120
@REPLY: 2:221/1.58@fidonet ef616eac
@MSGID: 1:153/7001 sTW6u3OA
@CHRS: UTF-8 4
-={ 2021-04-13 21:15:41.032014984+00:00 }=-
Test reply to see if WP now handles those invalid MSGID values
nicer ;)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 368 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 86:45:33 |
| Calls: | 7,895 |
| Calls today: | 1 |
| Files: | 12,968 |
| Messages: | 5,792,151 |
