🚀 go-pugleaf

In article <1990Sep24.220833.230@vicom.com> lmb@vicom.com (Larry Blair) writes:

>Bug 2: (or maybe not)

>The path contained in the reposting shows `Path: vsi1!vsi1!...'.  I'm pretty
>sure that 2.11 checked for your site in the path to prevent propagation loops.

	I've been seeing exactly the same problem, and was starting to
wonder if I was hallucinating. [some of our month old+ news has leaked
back out onto the net - thanks to those of you who have pointed this
out] I'm running Cnews, patchlevel "most recent that I know of" :)

	If I post an article with a path like
Path: deucac!decuac.dec.com!decuac!decuac.dec.com!mjr

	it propagagates out just fine.

	We're also getting (though I hope that's fixed, now) articles making
a long, slow loop, and reaching our machine after their history entries have
expired here, and going back around. What's the best way to ensure against
this kind of problem ? I wonder if various Cnews sites have been lucking
out by virtue of Bnews sites "compartmenting" article loops...

mjr.

In article <1990Sep24.220833.230@vicom.com> lmb@vicom.com (Larry Blair) writes:
>... by removing the Message-ID and using `inews -d local'.
>Unfortunately, our version of C News (PL 18, if you were counting) only
>inserts `Distribution: local' if there is no Distribution header already
>present...

I don't think it has ever been clear what the semantics are supposed to be
if the same header crops up in both inews options and the article itself.
(Actually, we think most of the inews options are silly ideas, since it's
no harder to just plug the header into the article.)

>The path contained in the reposting shows `Path: vsi1!vsi1!...'.  I'm pretty
>sure that 2.11 checked for your site in the path to prevent propagation loops.
>C News obviously doesn't.  Is this a bug (or a feature :-)?  The path has to
>be scanned to determine whether to pass the article or not so why not check to
>see if your site is already in the list?

It's one more check to do on a critical path, and one that in normal (and
most abnormal) circumstances serves no purpose.  Loop breaking is normally
done by your neighbors not sending you the article, not by you recognizing
that it's yours.
-- 
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry

In article <1990Sep24.220833.230@vicom.com> lmb@vicom.com (Larry Blair) writes:
>The path contained in the reposting shows `Path: vsi1!vsi1!...'.  I'm pretty
>sure that 2.11 checked for your site in the path to prevent propagation loops.

I don't think that it should.  Checking the path to see if a site is
already listed is an optimization performed by the SENDER.  It is
important for UUCP feeds to non-leaf sites.  The real protections against
duplicates are the message ID and posting date.  Articles older than what
is retained in the history file should be discarded.

I think it is a bad idea to rely to heavily on the path because there is
no guarantee against duplicate news names.  Before someone mentions the
UUCP map project remember that is for UUCP, not news.  There are sites
that run news without UUCP and sites that just don't register.

As a specific example I was sending an aged ihave to sun.com with all
the articles from the previous day.  I monitored the articles they were
requesting (finding a minor bug in my sys line for them) and noticed
that they were also requesting articles that they should have received.
A little further investigation showed that those articles alread had
"sun" in the path so none of sun.com's neighbors were sending them to
sun.

The problem was that the "sun" in question was "sun.soe.clarkson.edu".
So, any articles originating on or passing thru the other "sun" won't
get to sun.com.  As there is no official control, or even registration,
of news sites there is no mechanism to prevent such naming clashes.
If sun.com rejected those articles then it was doing the wrong thing as
it had never seen them before.

I wonder how the small amout of overhead C news saves by not parsing the
date compares to the CPU, modem, and PEOPLE overhead spent on processing
recirculated expired articles.

				Jerry Aguirre