Text 24036, 99 rader
Skriven 2015-04-24 19:52:29 av Wilfred van Velzen (2:280/464)
     Kommentar till en text av Bill McGarrity (16036.2fidonews)
Ärende: Re: Dupes...
====================
* Originally in FIDONEWS
* Crossposted in SYNCHRONET

Hi Bill,

On 2015-04-23 22:44:00, you wrote to All:

 BM> OK, reply from Rob on the issues of dupe checking.  He is speaking
 BM> about Joe's system as that is who Wilfred was originally talking
 BM> about.

 DM>> If the seen-bys were in-fact stripped, then when Joe's system received
 DM>> the message a second time, it would not know it's a duplicate until it
 DM>> performed a duplicate message check. If the message was indeed a
 DM>> duplicate, then it would not be imported into Joe's system *or*
 DM>> forwarded to his links.

 BM> So this takes care of one of the issues that was discussed.  Before a
 BM> message gets forwarded it is checked.

That is not what Rob told me and Joe last year:

 On 19-Jan-14 22:58, Rob Swindell wrote:

 RS> Joe,

 RS> SBBSecho only checks for duplicate messages when importing into a
 RS> local message base. If you're a hub for an echo, any messages you
 RS> receive from one link (up or downlink) will be propagated to the
 RS> others without any dupe checking.

 RS> -Rob

 On Tue, Jan 21, 2014 at 10:08 PM, Rob Swindell <rob@synchro.net> wrote:

 RS> Wilfred,

 RS> The duplicate message checking occurs in the Synchronet Message Base
 RS> (SMB) library, which is not specific to FidoNet or any other
 RS> networking technology. So whether a message is imported via QWK, NNTP,
 RS> SMTP, PostLink, FTN, or whatever- future-networking-technology, it is
 RS> subjected to the same database of hashes to detect duplicates.

 RS> When an FTN message packet is processed by SBBSecho but the message is
 RS> not imported into a local message base (e.g. pass-through area or
 RS> passing between up/downlinks), the SMB library is thus not involved
 RS> (the message would go straight from one FTN packet to another FTN
 RS> packet), never touching a Synchronet message base.

 RS> -Rob

So I think you miss understood what Rob is saying in his reply to you?

 DM>> Instead, what I think is happening, is the seen-bys were *not*
 DM>> stripped, so Joe's system recgonizes this as a circular path message
 DM>> (due to his address already existing in the SEEN-BYs), does not bother
 DM>> with any dupe checking, and then forwards the message to his links.

 BM> This could be an issue everyone seems to worried about.

I would call it a bug. But Rob fixed it with the new option...

 DM>> Joe could easily change this behavior by disabling the Circulat Path
 DM>> checking in sbbsecho (adding NOPATHCHECK to his sbbsecho.cfg or
 DM>> enabling the equivalent option in EchoCfg) - this would require no
 DM>> change to SBBSecho.

 BM> One fix....

 DM>> Alternatively, Joe could leave circular-path detection enabled (which
 DM>> I think is a good thing) and I could add an option to SBBSecho to
 DM>> *not* forward circular messages to links. This would not require dupe
 DM>> checking at all.

 BM> This is the fix I asked Rob to do.

Why would he make it an option and not the default behaviour. I can't think of
a reason why you want to forward circular messages (for the second or third or
... time).

 DM>> So to recap: SBBSecho's dupe checking works fine and indeed duplicate
 DM>> messages are detected *before* sent to links (and dupe messages are
 DM>> not forwarded). However, a detected circular path prevents any
 DM>> duplicate message checking and this is the area for potential change
 DM>> in behavior.

 BM> So there is the explaination.  Hopefully within a few weeks the new option
 BM> can be added to SBBScho so all bases are covered.  Right now I've added
the
 BM> NOCHECKPATH to see if that at least helps.  Just know IF duplicate MSGID
 BM> are detected, they are stripped before being sent to links.

Strip MSGID's? That would be a very big bug! ;)


Bye, Wilfred.

--- FMail-W32-1.69.4.102-B20150403
 * Origin: Native IPv6 connectable node (2:280/464)