TIP: Click on subject to list as thread! ANSI
echo: tub
to: Mark Lewis
from: Dieter Ringhofer
date: 2002-11-29 11:07:18
subject: Squish dupe detection.

Hi Mark!

 DR>> Gigo is known to be a dupe catapult since many years.

 ml> what's wrong with the KEEP_THREADS option?

Sorry, I'm not familiar with Gigo and don't know what this features offers
for this. I have put it into trash after having a look at it many years ago
due to it's msgid handling.

The problem with Gigo is it's way to deal with msgids. Take following
scenario of dealing with any posting:

 FTN1 - Gigo - RFC - Gigo - FTN2

Means:
At system FTN1 somebody posts something. You have a Gigo based gateway to
RFC (news) there as well. Another system picks up this posting from RFC and
uses Gigo to gate it to FTN.

When having a close look at this posting you'll encounter THREE different
msgids in dependancy on where you pick it:

1. the real one
2. the one generated by Gigo at first gate
3. the one generated by Gigo at second gate

Now you can link systems FTN1 and FTN2 (they feed each other directly or
via many other systems). What happens?

FTN1, where posting originates, gets the very same posting from FTN2 and is
unable to identify it to be a dupe. Gigo performs gating again, ... .

You will have a mail running in a never ending loop!

It doesn't matter where posting originates in reality (RFC, FTN, ...).
Effect is always the same:

Gigo produces "new" postings.

 DR>> Therefore it's recommended to get rid of it or to use it only
 DR>> when you are not feeding any other system. ...

 ML>>> I'll try some batch file magic on the incoming ...

 DR>> I don't believe you will be very successfull. Instead of ...

 ml> the sources for GIGO are available and this stuff could be fixed...
 ml> hummm... maybe i'll approach the author and see about him putting it on
 ml> sourceforge for group development and refinement...

Several years ago author of Gigo has been asked to fix this behaviour and
he refused to do it.

Over here in Germany you'll encounter many FTN-RFC gateways but, AFAIK most
of them use Fidogate or parts of it at least. Any gate will be closed very
fast when first dupe is encountered.

Reason for high grade of sensibility about this is our cost structure when
it comes to telephon: There's no free ride normally (only with one company
and there only on sunday when you sign a specific contract). Most often
it's cheaper to do long distance calls instead of doing local calls.
Therefore we don't have a defined routing structure except of several
systems being the "backbone", region and maybe zone gates. It
looks like a chaotical knot. This chaotical system works fine since years
and: Nobody can destroy it (we had such an exercise in 1993).

cu, Dieter

---
* Origin: Wndos s god fr cmnicaton (2:2476/14)
SEEN-BY: 10/345 20/11 106/1 2 3 1234 2000 112/91 116/116 117/100 123/140 500
SEEN-BY: 123/789 128/187 130/803 142/906 143/2 150/220 167/133 226/600
SEEN-BY: 229/1000 2000 3000 249/116 261/38 1466 267/200 280/5003 333/0 342/3
SEEN-BY: 346/3 365/3253 379/1 1200 397/1 633/267 270 712/848 774/605
SEEN-BY: 2404/201 2624/306 3613/1275 3618/555 3800/1 3830/9
@PATH: 2476/14 2410/201 774/605 123/500 106/1 379/1

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.