Subj : Squish dupe detection. To : Mark Lewis From : Dieter Ringhofer Date : Sat Nov 30 2002 02:53 pm Hi Mark! ml> what version of the source code? it might be something that could help ml> unless it is after such was released to the public... IIRC it's the version being released. I must do some digging... DR>> I could also watch what happens when some newbie activated DR>> a gate using Gigo. ml> hunh? Yep. There has always been a dupe wave afterwards. :-( ml>>> SAFE_THREADS maintains a local database of MSGID, References ... DR>> Here you have the reason when you don't have an "encapsulated DR>> circuit" for messages being gated with Gigo. In the very DR>> moment such a message leaves that circuit (comes to another DR>> system which carries original message) it is a dupe but cannot DR>> be identified. ml> ahhh... that would indicate that SAFE_THREADS is only good for local bases ml> and not echo areas... As long as it's ensured that there's no further connection to the world you can use it for echo areas as well. Trouble arises in the very moment when somebody establishes an additional connection. ml>>> the May 24, 1994 version contained specific work done for squish ml>>> problems... DR>> This assumption maybe is ... hmm... not fully correct. Squish DR>> 1.10 needs some specific setup to work correct (see my DR>> previous posting about this). ml> yes, i'm aware that squish has numerous shortcomings... Uh?? I'm not aware of anything being worth to be called "shortcomming". I use Squish since many years, used it with up to ten FTNs and performed complete routing in hub/host position (route.cfg > 50kB). F.e. with Fastecho it wouldn't be possible to do what I have done with Squish. I have registration keys of every important tosser and never left Squish. To save some time and to make my live easier a little bit I installed a tracker (Itrack) few years ago. That's all over here, it's a simple system using a real workhorse. :-) DR>>>> FTN1 - Gigo - RFC - Gigo - FTN2 DR>>>> When having a close look at this posting you'll encounter DR>>>> THREE different msgids in dependancy on where you pick it: DR>>>> Now you can link systems FTN1 and FTN2 (they feed each other DR>>>> directly or via many other systems). What happens? ml>>> a dupe loop that would happen just like it would for echomail... DR>> With normal echomail this is no real problem because recipient DR>> system is able to identify dupes when msgid is not altered. DR>> Such a dupe will not be exported anymore. ml> true... that is why there was developed a method that all systems would ml> "calculate" the same info for the MSGID... however, i seem to recall that ml> it was a bit "short" in its working... Such a system can't work without a common central system. Standalone mode would cause production of very same msgid at multiple systems at some time. Each method being used to calculate msgids has it's shortcommings but, it what has been developed so far looks like working fine or sufficient at least. ml>>> no matter... if GIGO is put on sourceforge someone can still ml>>> fix this problem if it is still a problem... DR>> This will be a problem as long as original msgid is not DR>> preserved and included as such in any message. ml> so you are recommending "converting" the original RFC Message-ID to the ml> "originating system" portion of the MSGID? then what to do for the "serial ml> number" portion? or just carry the original Message-ID in full as another ml> control line? The original msgid must be preserved as such. One can add other controls but, changing msgid is a very big NoNo. DR>>>> Over here in Germany you'll encounter many FTN-RFC gateways DR>>>> but, AFAIK most of them use Fidogate or parts of it at least. DR>>>> Any gate will be closed very fast when first dupe is DR>>>> encountered. ml>>> the same happens (or should) when any echomail dupe loop is ml>>> discovered... DR>> There's no real distribution when software being used for DR>> gating works as it should be. ml> there is if an area is being passed from one system (the gateway) to ml> numerous others... isn't there? That's correct. Sorry, I wrote an inclomplete sentence. :-( It should be ...no real distribution of dupes when ... . ml>>> however, we must also note that some dupe loops are by design... ml>>> consider a fully connected backbone network... ml>>> hubA=========hubB ml>>> | \ / | ml>>> | \ / | ml>>> | \ / | ml>>> | \ / | ml>>> | \ / | ml>>> | X | ml>>> | / \ | ml>>> | / \ | ml>>> | / \ | ml>>> | / \ | ml>>> | / \ | ml>>> hubC=========hubD DR>> No problem at all. We did similar over here for long time to DR>> ensure and speed up distribution of mail. Dupe prevention is DR>> done when each hub feeds specific systems which have DR>> absolutely no feed in direction to another hub. It needs some DR>> discipline at downlink side but works fine when this is given. ml> this is how both (Z1B and NAB) distribution systems are connectied here in ml> Z1... only they each have more than four systems as shown above in that ml> simple diagram... R24 backbone works similar. Additionally there are "sleeping" systems being located like an enclosing ring "around" this backbone. In case of real trouble we should be able to fix every problem within less than 24 hours. ml>>> dupes are a way of life and required to ensure proper message ml>>> propogation... however, those dupes should not be sent to ml>>> systems linkedoff each hub... DR>> Change msgid and things will become much more worse. :-) ml> i'm sure... we have that problem from time to time with fubar software ml> still in use... wildcat and PC Board stuff used to be the worst... wildcat ml> especially after an upgrade to a newer version... it used to export entire ml> message bases back into the distribution system... Well, I have the very same problem due to tossers which perform dupechecking over all areas (Squish' dupe checking is dedicated to each and every area): I run the gateway to and from MxBBSNet (Zone 256). I had to exchange gateway software because of dupechecking and NoBogus (it complained about some irrelevant things and stopped delivery for this). Now there's the problem of "illegal links" like it exists with Gigo. At some time some people tried to do open additional links and caused dupes for this but seenby-adding fixed it very fast... cu, Dieter --- * Origin: Wndos s god fr cmnicaton (2:2476/14) .