jbuck@epimass.EPI.COM (Joe Buck) (04/02/88)
In article <47838@sun.uucp> chuq@sun.UUCP (Chuq Von Rospach) writes: >>This "bug" prevents your transmitting the news items you receive back >>to your newsfeed. >>And maybe them sending it back to you, and you to them ...... > >It prevents transmiting it back, but the loop prevention is the reason >why we have the history file. It comes back, it's recognized as a duplicate, >it dies. Chuq is right on this one. Message-IDs and the history file are sufficient to prevent loops. They aren't sufficient to prevent wasted transmissions of articles; getting rid of Path: will significantly increase backbone news traffic (adding roughly one full feed's worth of traffic), since every backbone site talks to at least two others and passes full feeds back and forth. >This "bug" also prevents a message published in the name of someone >on a given site (a common occurance for moderated groups) from ever >being posted on the machine in question or any site downstream of them. It most emphatically does not! Some moderators mistakenly try to make the Path: be a reply address to the original poster. This is incorrect; read the RFCs. The Path: header should include the sites, and only the sites, where the article has been AS A NEWS ARTICLE. The From: and Reply-To: lines can (and should) be set to point to the original poster. The bug, if any, is moderators violating the spec. >On balance, this 'feature' is more of a pain than a convenience. This "feature" saves substantially on phone bills for anyone with more than one incoming feed and makes bidirectional feeds practical and economical. It encourages people to add redundancy to the net without imposing an excessive cost penalty. If an article comes to my site and is then rejected, someone has already paid for sending it. Since you're asking for a change that will increase the cost of operation of the backbone, it seems to me that you're not going to get anywhere. >>Sounds like a good reason to register one's sitename. If newsfeeds were >>routed only to registered sites, the problem wouldn't occur. > >Nice idea. Wishful thinking, but nice idea. Since registering is (and always >will be) voluntary, registering will never keep this from happening, since >both sides of a dispute need to register for the conflict to be resolved. >What if I decide to (or don't know I'm supposed to) not register. How do you >find out about me? The first thing that people at the non-registered site will find out is that they don't get any mail replies; the mail replies will be routed to the registered site (all mail from news sites with INTERNET defined, as well as all mail that passes through a site that does aggressive autorouting, will aim it at the registered site). The postmaster or system administrator at registered site will start to notice these odd replies. That's how you find out that someone is using your name. Note that it's not necessary to register your name to be "legit"; it's just that "Reply-To: user@foobar.UUCP" means "the foobar that appears on the UUCP map". You can always hack your news to generate reply addresses like "user%mysite@registered-site.domain", assuming that registered-site knows how to mail to you. -- - Joe Buck {uunet,ucbvax,sun,<smart-site>}!epimass.epi.com!jbuck Old Internet mailers: jbuck%epimass.epi.com@uunet.uu.net
ejbjr@ihlpg.ATT.COM (Branagan) (04/05/88)
In article <2047@epimass.EPI.COM>, jbuck@epimass.EPI.COM (Joe Buck) writes: > In article <47838@sun.uucp> chuq@sun.UUCP (Chuq Von Rospach) writes: > >>This "bug" prevents your transmitting the news items you receive back > >>to your newsfeed. > >>And maybe them sending it back to you, and you to them ...... > > > >It prevents transmiting it back, but the loop prevention is the reason > >why we have the history file. It comes back, it's recognized as a duplicate, > >it dies. > > Chuq is right on this one. Message-IDs and the history file are > sufficient to prevent loops. So far, so good. Message IDs and history indeed are sufficient to prevent loops. They are also NECESSARY to prevent duplication of articles recieved from multiple independent paths through the network. > They aren't sufficient to prevent > wasted transmissions of articles; This however is not true. Rather than checking the Path:, it would be possible to ask the remote machine if it already has a given message ID in its history file BEFORE transmission, rather than waiting to check locally on the remote machine after transmission. This would be perfectly sufficient to prevent retransmission of articles back and forth between machines. It would also prevent the tremendous amount of wasted transmission of articles by multiple paths through the network for which the Path: header is not sufficient. > getting rid of Path: will > significantly increase backbone news traffic (adding roughly one > full feed's worth of traffic), since every backbone site talks to at > least two others and passes full feeds back and forth. Only if article transmission continues to ignore the existence of history (i.e. eliminating Path: WITHOUT adding a history check would significantly increase network traffic. Eliminating Path: and using history instead would DECREASE network traffic). So why don't we use history instead? Anything that would decrease the cost of the net would seem obviously worthwhile. The answer seems equally obvious. HISTORY. When the origonal netnews software was written, and the network was much smaller (<20 machines) and more structured Path: was sufficient to prevent retransmission - there weren't multiple paths through the network to cause unnecessary retransmission. As the network grew this "problem" was ignored - it wasn't a big enough problem to be worth solving until the network grew to be so large as to make a solution a major, expensive hassle. Past history tells us it is impossible to make coordinated changes in netnews software on such a large anarchistic network. Hence any change made would have to be made in an upward compatible manner and phased in slowly over the next umpteen years. Someone would have to invest significant time and effort to implement a history/message ID based handshaking in the news transmission software - including a new field in the appropriate system files to tell which transmission scheem to use for each machine to which a given upgraded machine talks. Anybody want to invest the time to design, implement, test and introduce such a feature? I didn't think so. Perhaps cost of unnecessary transmission will eventually force the backbone to propose and implement a solution. Does anybody have or care to generate statistics on the cost of unnecessary transmission by multiple paths? Without some estimate of the potential savings it will be impossible to justify such an effort and the almost-gaurenteed chaos which would temporarily result from a major change in transmission protocall. Before I stick my foot too far down my throat, does such a protocall already exist? Based on my limited knowledge of netnews internals and the discussion I've seen here, I don't think so. If it does, could someone more knowledgable tell us about it? If it does exist, is it limited to major backbone sights? - if so should it be more widely distributed? Note that the Path: header would still be needed - as an audit trail to track down problems like sites which mangle headers. It would be nice if the Path: header were more hidden though, to prevent attempted misuse. -- ----------------- Jim Branagan ihnp4!ihlpg!ejbjr (312) 416-7408 (work)
root@nccnat.UUCP (Paul Shields) (04/06/88)
In article <442@ontenv.UUCP>, soley@ontenv.UUCP (Norman S. Soley) writes: > In article <5137@ihlpg.ATT.COM>, ejbjr@ihlpg.ATT.COM (Branagan) writes: ... [much about retransmission of articles...] > Doesn't this already exist in the form of ihave/sendme? > > : This would be perfectly sufficient to prevent retransmission of > : articles back and forth between machines. > > Yes but at what cost, There are two costs to maintaining a link; the > time required to transmit your data and the time the line sits idle > while you process things. Don't have the line sit idle. If you run out of work to do, hang up. Call back when there's enough work to justify the reconnection, ie: if you have at least 2 minutes worth of data to transfer over the long-distance line. This discussion reminds me of something I've been thinking about. Why not have the redundant connections handled by smart use of the UUCP map data? Here's an example of wastage of long-distance connections: Suppose you have two backbone sites in the same city. Each one is getting articles from some remote site or sites, resulting in duplication of long distance charges. But you need the redundancy, because one of the backbones in the city may go down. The solution here is to use a modified ihave/sendme protocol which DELAYS transmission of an article to one backbone if it is likely that the article will arrive at the other backbone first. If one of the backbones goes down, the article still gets through eventually, but we avoid the duplicate transmission. Note, that this need not be an isolated case. The two backbones in question don't HAVE to be in the same city for you to get some savings out of this method -- they must only be closer to each other than to the remote site. -- Paul Shields: shields@yunccn.UUCP or yunccn!nccnat!root. Communication is a two-way street. Don't get run over.
soley@ontenv.UUCP (Norman S. Soley) (04/07/88)
In article <5137@ihlpg.ATT.COM>, ejbjr@ihlpg.ATT.COM (Branagan) writes:
: So far, so good. Message IDs and history indeed are sufficient to
: prevent loops. They are also NECESSARY to prevent duplication of
: articles recieved from multiple independent paths through the
: network.
: > They aren't sufficient to prevent
: > wasted transmissions of articles;
: This however is not true. Rather than checking the Path:, it would
: be possible to ask the remote machine if it already has a given
: message ID in its history file BEFORE transmission, rather than
: waiting to check locally on the remote machine after transmission.
Doesn't this already exist in the form of ihave/sendme?
: This would be perfectly sufficient to prevent retransmission of
: articles back and forth between machines.
Yes but at what cost, There are two costs to maintaining a link; the
time required to transmit your data and the time the line sits idle
while you process things. Requiring history checking will reduce the
first no doubt but would also certianly increase the idle time.
: It would also prevent the tremendous amount of wasted transmission
: of articles by multiple paths through the network for which the Path:
: header is not sufficient.
When is this the case? I know the Path: line can mess you up if your
name is a subset of someone elses but barring that when does Path:
break down?
: > getting rid of Path: will
: > significantly increase backbone news traffic (adding roughly one
: > full feed's worth of traffic), since every backbone site talks to at
: > least two others and passes full feeds back and forth.
: Only if article transmission continues to ignore the existence of
: history (i.e. eliminating Path: WITHOUT adding a history check
: would significantly increase network traffic. Eliminating Path:
: and using history instead would DECREASE network traffic).
: So why don't we use history instead?
See above, traffic decreases but connect time (i.e. what the phone
company charges us for) increases.
: Before I stick my foot too far down my throat, does such a protocall
: already exist? Based on my limited knowledge of netnews internals
: and the discussion I've seen here, I don't think so. If it does,
: could someone more knowledgable tell us about it? If it does exist,
: is it limited to major backbone sights? - if so should it be more
: widely distributed?
Ihave/Sendme does this and it's a part of regular netnews if you turn
it on. Personally I only take news from 1 feed so I don't have a
multi-path problem. I don't know how extensively Ihave/Sendme is used
in the more connected part of the net.
: Note that the Path: header would still be needed - as an audit trail to
: track down problems like sites which mangle headers. It would be nice
: if the Path: header were more hidden though, to prevent attempted
: misuse.
And the INTERNET define should be....OK so that's another war...I'll
shut up about it.
--
Norman Soley - Data Communications Analyst - Ontario Ministry of the Environment
UUCP: utzoo!lsuc!ncrcan!---\ VOICE: +1 416 323 2623
{utzoo,utgpu}!sickkids!ontenv!norm ENVOY: N.SOLEY
{mnetor,utgpu}!ontmoh/elg@nuchat.UUCP (Eric Green) (04/08/88)
From article <2047@epimass.EPI.COM>, by jbuck@epimass.EPI.COM (Joe Buck):
$ In article <47838@sun.uucp> chuq@sun.UUCP (Chuq Von Rospach) writes:
$>>This "bug" prevents your transmitting the news items you receive back
$>>to your newsfeed.
$>It prevents transmiting it back, but the loop prevention is the reason
$>why we have the history file. It comes back, it's recognized as a duplicate,
$>it dies.
$ Chuq is right on this one. Message-IDs and the history file are
$ sufficient to prevent loops. They aren't sufficient to prevent
$ wasted transmissions of articles; getting rid of Path: will
Hate to break in to a conversation, but isn't this exactly what
"IHAVE"/"SENDME" messages are supposed to avoid? That is, the sender
say "I have these messages" and the reciever saying "OK, send me
messages x,y,z"?
I don't know if news software has reached that level of sophistication
yet, but it IS possible. If everybody runs late-model
news software, that is.
--
Eric Lee Green P.O. Box 92191 Lafayette, LA 70509
uunet!nuchat!elg "I survived the Flood of '88"