Hello
I would like to know if anyone has experience using sbbs as a fidonet hub. Being sbbs a node that distributes to other nodes
Without external tools, using binkit.js, sbbsecho, tickit.js, etc.
Currently I have a node and I distribute to points and this works more or less well
But I am interested in knowing if this scenario is possible and functional
I would like to know if anyone has experience using sbbs as a fidonet
hub. Being sbbs a node that distributes to other nodes Without
external tools, using binkit.js, sbbsecho, tickit.js, etc.
sestar is one of the three top-tier backbone distribution systems in fidonet... it is also a FileGate FDN distribution HUB...
some things are missing (eg: announcing newly arrived and processed files) but those are just icing on the cake and not really necessary...
sestar is one of the three top-tier backbone distribution systems
in fidonet... it is also a FileGate FDN distribution HUB...
I find that SBBSecho is too agressive with dupes.
What I mean is new messages like monthly rules postings or BBS
ads are considered dupes even though they have a new MSGID and
time stamp in the message header they are considered dupes and
dropped.
some things are missing (eg: announcing newly arrived and
processed files) but those are just icing on the cake and not
really necessary...
Yes, I have found that too. I like the icing on my cake better
than the cake itself and find it necessary. :)
What I mean is new messages like monthly rules postings or BBS
ads are considered dupes even though they have a new MSGID and
time stamp in the message header they are considered dupes and
dropped.
exactly... this is because it checksums the message body and doesn't take the time stamps or MSGIDs into account...
Re: sbbs as fidonet hub
By: Rampage to Ragnarok on Tue Mar 30 2021 08:39 am
sestar is one of the three top-tier backbone distribution systems in fidonet... it is also a FileGate FDN distribution HUB...
I find that SBBSecho is too agressive with dupes.
What I mean is new messages like monthly rules postings or BBS ads are considered dupes even though they have a new MSGID and time stamp in the message header they are considered dupes and dropped.
What I mean is new messages like monthly rules postings or BBS ads are
considered dupes even though they have a new MSGID and time stamp in
the message header they are considered dupes and dropped.
You can turn off duplicate message checking (per sub-board) if you want duplicate message bodies to be imported. Duplicate MSGID checking cannot be disabled.
Re: sbbs as fidonet hub
By: Digital Man to Al on Tue Mar 30 2021 12:43 pm
What I mean is new messages like monthly rules postings or BBS ads are
considered dupes even though they have a new MSGID and time stamp in
the message header they are considered dupes and dropped.
You can turn off duplicate message checking (per sub-board) if you want duplicate message bodies to be imported. Duplicate MSGID checking cannot be disabled.
We don't want to disable duplicate message checking. These days I get two or more copies of most messages.
Sometimes messages like BBS ads or rules posting are reposted after a period of time so they get a fresh date and MSGID but the message body hasn't changed.
Without checking the header for a new message date or MSGID those messages are considered dupes and dropped.
That may or may not be an issue on a BBS but it is an issue for message flow in FTN networks. On our own BBS we might have seen a message before but our links may not have. These messages will not be forwarded by SBBSecho until the past message clears from the dupe database.
Maybe the MSGID could be checked in addition to the message body? That's more of a thought than a conclusion.
Yes, and thinking about the dupes we talked about a short time ago in FIDOTEST SBBSecho did catch that dupe, so we don't want to loose that capability.
Maybe it would be enough to check the MSGID and pass it if it is different?
Without checking the header for a new message date or MSGID those
messages are considered dupes and dropped.
Right. So disable the duplicate message checking. Duplicate MSGIDs will still be detected and dropped.
Maybe the MSGID could be checked in addition to the message body?
That's more of a thought than a conclusion.
It already is. The duplicate MSGID checking is a separate check that cannot be disabled.
Maybe it would be enough to check the MSGID and pass it if it is
different?
My understanding is that SBBSECHO tosses the messages while it relies upon the message base handler to check for duplicate messages. The aggressive nature of the duplicate checker is based on your own personal selection (number of CRCs to maintain).
Re: sbbs as fidonet hub
By: Digital Man to Al on Tue Mar 30 2021 03:36 pm
Without checking the header for a new message date or MSGID those
messages are considered dupes and dropped.
Right. So disable the duplicate message checking. Duplicate MSGIDs will still be detected and dropped.
I don't want to defeat duplicate checking. If I do disable duplicate message checking then I will have message checking based solely on MSGID?
There are still messages traveling the net with no MSGID so the only checking possible in those cases is duplicate message checking.
Maybe the MSGID could be checked in addition to the message body?
That's more of a thought than a conclusion.
It already is. The duplicate MSGID checking is a separate check that cannot be disabled.
That's not my experience. Currently I am seeing rules posts that have identical message bodies with a different MSGID detected as dupes and dropped.
Digital Man wrote to Al <=-
That's not my experience. Currently I am seeing rules posts that have identical message bodies with a different MSGID detected as dupes and dropped.
Right. If you have duplicate message checking enabled, then any
duplicate message body text is considered "dupe" and dropped. If
you don't want that behavior, disable the duplicate message
checking (and risk more dupes that have no/different MSGIDs).
It sounds like you're suggesting that *both* the text and the
MSGID should be compared and equal in order to be considered a
duplicate - to which I would ask: why bother? if the MSGID is a
duplicate, it's a duplicate. No need to compare the message body
in that case. But 2 messages with different MSGIDs but the same
body text is either a network screw-up or someone purposely or accidentally posting the same content repeatedly.
There's really
no way for software to tell the difference. But you can import
and forward those messages if you prefer to, you have that
option.
It sounds like you're suggesting that *both* the text and the MSGID should be compared and equal in order to be considered a duplicate -
to which I would ask: why bother?
These messages (rules posts or BBS ads) do have identical message
bodies but they have been newly posted, these are new posts with a
different MSGID.
What he's describing is what happens with automated BBS ads and/or echo rules postings (just two examples). Same body, different MSGID, and
they won't get distributed into the echos because the hub will drop it
as a dupe. Those aren't malicious/spam messages, but they get dropped.
fusion wrote to Gamgee <=-
On 31 Mar 2021, Gamgee said the following...
What he's describing is what happens with automated BBS ads and/or echo rules postings (just two examples). Same body, different MSGID, and
they won't get distributed into the echos because the hub will drop it
as a dupe. Those aren't malicious/spam messages, but they get dropped.
this, of course, nobody agrees on. i for one have removed just
about every area with a non stop barage of rules postings.. which
everyone ignores except the one stickler who wants to refer to
them. usually the otherwise completely dead area will spring back
to life the second you post though, because the one dude posting
the rules non stop doesn't agree with you and he's the only other
person there..
tbh i hate automated posts in general. every ham radio area on
every net i've been on is completely ruined with the same non
stop messages you get in your local club's mailing lists. and
when's the last time you met a ham that isn't on their local
club's mailing list?
Looks like your <SHIFT> key is broken, BTW. Do you actually prefer to not use proper capitalization?
It sounds like you're suggesting that *both* the text and the
MSGID should be compared and equal in order to be considered a duplicate - to which I would ask: why bother? if the MSGID is a duplicate, it's a duplicate. No need to compare the message body
in that case. But 2 messages with different MSGIDs but the same
body text is either a network screw-up or someone purposely or accidentally posting the same content repeatedly.
What he's describing is what happens with automated BBS ads and/or echo rules postings (just two examples). Same body, different MSGID, and
they won't get distributed into the echos because the hub will drop it
as a dupe. Those aren't malicious/spam messages, but they get dropped.
There's really
no way for software to tell the difference. But you can import
and forward those messages if you prefer to, you have that
option.
They realistically can't be forwarded, because the next system in the
link (probably a hub) will drop it as a dupe.
I *think* he's saying that if the MSGID's are different, the message
should not be considered a dupe, even if the body is identical to a
previous message. I agree with that thinking.
Re: sbbs as fidonet hub
By: Digital Man to Al on Tue Mar 30 2021 09:27 pm
It sounds like you're suggesting that *both* the text and the MSGID should be compared and equal in order to be considered a duplicate -
Yes, I think that would do what I am hoping to do.
to which I would ask: why bother?
These messages (rules posts or BBS ads) do have identical message bodies but they have been newly posted, these are new posts with a different MSGID. We still want to be vigilant about dupes, in fact today we must be vigilant about dupes.
Stepping away from the BBS side of this and looking at it from a mail flow point of view.. when linked to someones node, linked nodes have a reasonable expectation that they will receive all new messages in a given area that have been posted, and also that messages that enter the flow from their node will also be sent along to connected nodes.
Hence my position that the dupes should maybe only be
filtered out based on MSGID.
If the MSGID is duplicate, there's no point in comparing the message body text. You already know it's a dupe.
Re: sbbs as fidonet hub
By: Digital Man to Al on Wed Mar 31 2021 16:22:13
If the MSGID is duplicate, there's no point in comparing the message body text. You already know it's a dupe.
not always true...
Digital Man wrote to Gamgee <=-
There's really
no way for software to tell the difference. But you can import
and forward those messages if you prefer to, you have that
option.
They realistically can't be forwarded, because the next system in the
link (probably a hub) will drop it as a dupe.
I *think* he's saying that if the MSGID's are different, the message
should not be considered a dupe, even if the body is identical to a
previous message. I agree with that thinking.
Disable duplicate message checking and you will have that
behavior.
Digital Man wrote to Gamgee <=-
Hence my position that the dupes should maybe only be
filtered out based on MSGID.
And you have that option.
fusion wrote to Gamgee <=-
Looks like your <SHIFT> key is broken, BTW. Do you actually prefer to
not use proper capitalization?
ya
Yes, I think that would do what I am hoping to do.
If the MSGID is duplicate, there's no point in comparing the message body text. You already know it's a dupe.
I'm not clear what your definitino of "vigilant about dupes" means. If you only care about duplicate MSGIDs, then disable the duplicate message checking and that is what you will get - but *I* don't consider that configuration to be vigilant.
I hope that my uplink will deduplicate messages using effective measures. If he doesn't, then I will. Duplicates should be detected and removed as upstream as possible, in my opinion.
But if you want different behavior on your system, you have that option.
I feel like we're talking past each other and I'm not really sure how else to state it: if you want to allow multiple messages to be imported into your message bases and passed to downlinks with the identical message body text of a previously imported message, then disable the duplicate message checking in SCFG. This will have no impact on duplicate MSGID checking. There is no configuration setting to disable dulpicate MSGID checking.
I suppose it comes down to just what is a dupe. Is it a dupe if the msg body CRC is identical to a past post? That's a pretty good indication but I am suggesting we campare the MSGID of the two messages before we call it a dupe.
Currently SBBSecho is dropping new messages from the flow of traffic because it has incorrectly trapped them as dupes when they are in fact new posts.
not always true... just ask daryl stout of thunderbolt bbs about the
times i reported to him about his messages being detected as dupes
If the MSGID is duplicate, there's no point in comparing the message
body text. You already know it's a dupe.
not always true... just ask daryl stout of thunderbolt bbs about the times i reported to him about his messages being detected as dupes because the sofware he was using at the time was creating basically random MSGIDs and some were duplicates of others only a few months old... in some cases, it may have been attributed to reinstallations and/or the loss of a/the msgid file if there was such in use... in any case, i know that he can tell about
the problem... one of those packages was virtual advanced IIRC... there was
another one or two that he tried before setteling on synchronet...
I don't know how often it happens, because most probably go
undetected. I'm not reading my dupe area on a regular basis,
let alone scan it for false dupes... ;)
in any case, dupe checking in FTN is not done my /just/ detecting duplicate MSGIDs and rejecting the others... the header, including the time stamp, as well as the message body should be taken into
account...
it should also be said that CRC16/CRC32 on the message bodies is also
not sifficient... even with filtering out white space and the various EoLs... this because, and most programmers know this, there's a
limited supply of CRC values in the tables and it is all too easy to
find "hash clashes"... CRC16 has only 65536 values... CRC32 has only 4294967296 values... the "Birthday Problem" also comes into play...
these days, MD5 and SHA1 are also out due to defects in them...
SHA256 would be the first really useful algorithm or SHA512...
but the real key is to filter out the stuff that can change and hash
only that which won't...
anyway, i'm done with this topic in this area... the discussion really belongs elsewhere for those that are truely interested in implementing proper duplicate detection in FTNs...
in any case, dupe checking in FTN is not done my /just/ detecting duplicate MSGIDs and rejecting the others... the header, including the time stamp, as well as the message body should be taken into account...
it should also be
said that CRC16/CRC32 on the message bodies is also not sifficient... even with filtering out white space and the various EoLs... this because, and most programmers know this, there's a limited supply of CRC values in the tables and it is all too easy to find "hash clashes"... CRC16 has only 65536 values... CRC32 has only 4294967296 values... the "Birthday Problem" also comes into play...
these days, MD5 and SHA1 are also out due to defects in them...
SHA256 would
be the first really useful algorithm or SHA512... but the real key is to filter out the stuff that can change and hash only that which won't...
anyway, i'm done with this topic in this area... the discussion really belongs elsewhere for those that are truely interested in implementing proper duplicate detection in FTNs...
in any case, dupe checking in FTN is not done my /just/ detecting
duplicate MSGIDs and rejecting the others... the header,
including the time stamp, as well as the message body should be
taken into account...
Dupe checking in FTN is done via many methods - its implementation dependant. SBBSecho does not take the time stamp of the message
into account when considering if a message is a duplicate.
anyway, i'm done with this topic in this area... the discussion
really belongs elsewhere for those that are truely interested in
implementing proper duplicate detection in FTNs...
Okay, then I guess you won't see this reply. <shrug>
I don't want to defeat duplicate checking. If I do disable
duplicate message checking then I will have message checking
based solely on MSGID?
I don't want to defeat duplicate checking. If I do disable
duplicate message checking then I will have message checking
based solely on MSGID?
Have you considered appendingprepending the date-time to your autopost content?
Deepend wrote to Ragnarok <=-
Any detailed information on using SBBS as a hub for a FTN network? I
have been wondering the same thing but Either I'm not looking hard
enough or the FTN tools are still too new to have good documentation
for certain uses but Any information on the procedures to setup a SBBS
as a Hub for a FTN network would be appreciated.
Deepend wrote to Ragnarok <=-
De> Any detailed information on using SBBS as a hub for a FTN network? I
De> have been wondering the same thing but Either I'm not looking hard
De> enough or the FTN tools are still too new to have good documentation
De> for certain uses but Any information on the procedures to setup a SBBS
De> as a Hub for a FTN network would be appreciated.
I don't know what information's out there, some of the tools are a bit new.
It's possible, I'm Fidonet RC10 and a hub for Micronet. I'm using Synchronet as a mailer/areafix manager and hosting file echoes. I'm using Makenl to create the nodelist segments and it all mostly works OK.
Before this setup, I used Argus as a mailer, Allfix for file processing, and sbbsecho for message area requests and mail tossing.
The only thing missing at this point, and I need to look into it more, is passthrough requests for file areas. I don't carry a lot of them, and would like to have the ability to pass on file echoes without hosting them.
The wiki entries on binkit and tickit are pretty good. Nodelist support in Echocfg gets a little tricky if you're a hub for more than one network.
The #synchronet IRC channel on DOVEnet is a good place to ask for help when you're setting things up. I'm usually on tilde.club lately, I'm currently going through a #trivia phase... :)
... How did you find this place?
--- MultiMail/DOS v0.52
¨ Synchronet ¨ realitycheckBBS -- http://realitycheckBBS.org
Any detailed information on using SBBS as a hub for a FTN network? I have been
wondering the same thing but Either I'm not looking hard enough or the FTN tools are still too new to have good documentation for certain uses but Any information on the procedures to setup a SBBS as a Hub for a FTN network would
be appreciated.
Ragnarok wrote to poindexter FORTRAN <=-
Very good, I'm thinking of being a hub.
I am missing the part about using makeNL, but the documentation
confuses me a bit, (unfortunately there is no documentation in Spanish yet)
Can you share your expertise? i'm search for real world example for
begin play with it
Using passthrough is not complicated, you have to configure in echocfg
in each echolist it has the data of the areafix of your uplink
and the "Forward AreaMgr Request" option to true.
*waves*
Hey Mike, long time to see. What are you wanting to do? I'm that other
crazy Calgary guy and would be happy to help.
---
Synchronet The Undermine - bbs.undermine.ca:423
I don't know what information's out there, some of the tools are a bit new.
It's possible, I'm Fidonet RC10 and a hub for Micronet. I'm using Synchronet as a mailer/areafix manager and hosting file echoes. I'm using Makenl to create the nodelist segments and it all mostly works OK.
Before this setup, I used Argus as a mailer, Allfix for file processing, and sbbsecho for message area requests and mail tossing.
The only thing missing at this point, and I need to look into it more, is passthrough requests for file areas. I don't carry a lot of them, and would like to have the ability to pass on file echoes without hosting them.
The wiki entries on binkit and tickit are pretty good. Nodelist support in Echocfg gets a little tricky if you're a hub for more than one network.
The #synchronet IRC channel on DOVEnet is a good place to ask for help when you're setting things up. I'm usually on tilde.club lately, I'm currently going through a #trivia phase... :)
... How did you find this place?
Hey underminer. Not sure what my exact plan is yet.. but want to set something
up to test and learn so I actually can do something when its needed. Pretty sure I've actually sent you netmail or something within the last month.. or atleast I thought I did.. maybe it didn't go through for some reason.
Deepend wrote to poindexter FORTRAN <=-
If you could possibly share some more detail on how you have things
setup it'd be very helpful. More detail the better if you don't mind
:)
| Sysop: | Xerxes |
|---|---|
| Location: | Azle, Texas |
| Users: | 131 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 85:49:20 |
| Calls: | 3,190 |
| Calls today: | 1 |
| Files: | 195 |
| U/L today: |
0 files (0K bytes) |
| D/L today: |
0 files (0K bytes) |
| Messages: | 366,067 |
| Posted today: | 0 |