Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/15/85; site cbosgd.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!cbosgd!mark
From: mark@cbosgd.UUCP (Mark Horton)
Newsgroups: net.news
Subject: Re: a harmless query...
Message-ID: <1134@cbosgd.UUCP>
Date: Sat, 4-May-85 17:28:42 EDT
Article-I.D.: cbosgd.1134
Posted: Sat May  4 17:28:42 1985
Date-Received: Sun, 5-May-85 04:03:35 EDT
References: <185@greipa.UUCP>
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 40

This is essentially correct.  Most hosts on the net are on the
fringes somewhere and get all their news from one place.  So
such duplications don't affect them.  There are many hosts, however,
that exchange news with 2 or 3 (or more) hosts, and they will get
(and throw away) a good number of messages they have already seen.

The reason for this duplication is for reliability.  A lot of things
can go wrong with a news link, and if one neighbor is your only source
of news, you may miss 10% (or more, depending on how robust your
neighbor and your link to this neighbor are) of the news.  There are
also speed arguments - you get news faster if you keep the first of
several copies that come in.  There is no real potential for saving
money by cutting back on duplicate feeds; hosts that are this concerned
about money probably already have only one feed.

There is potential for saving money here by only sending news that
has not already arrived on the machine in question.  A few simple
efforts along these lines are already in the code (for example, it
won't send news to a host in the Path: line, since it knows that host
has already seen it, or to the host the article originated on.)

An interactive protocol for only sending message that have not arrived
yet is very hard, given the dialup/batch nature of UUCP.  There is no
way to get interactive IPC between two news processes over UUCP.  You
can get interactive IPC over TCP/IP links, but these are rarely over
dialup lines, so there's no incentive to write the code.

There is a protocol in news called "ihave/sendme" in which only a
Message-ID is sent over the wire ("ihave xxx") instead of the whole
message; then the other system sends back the Message-ID's of messages
it doesn't already have ("sendme xxx"), and then the first system sends
it.  There isn't any savings, because the headers are often bigger than
the message body, and there is a considerable time delay for the 3 way
handshake (especially if the connection is polled.)  It seems reasonable
that by batching these (sending one message with 50 or more message ID's
in it instead of separate messages) there would be significant cuts in
phone bills (but the delay would still be there), and the method for
doing this is documented, but I haven't seen anybody actually implement it.

	Mark Horton