Path: utzoo!yunexus!gen1!yunccn!nccnat!root
From: root@nccnat.UUCP (Paul Shields)
Newsgroups: news.admin
Subject: Re: No longer about April Fools (the Path: header)
Summary: preventing duplicate articles, ihave/sendme + UUCP MAPS
Message-ID: <273@nccnat.UUCP>
Date: 6 Apr 88 16:14:19 GMT
Article-I.D.: nccnat.273
Posted: Wed Apr  6 12:14:19 1988
References: <1590@sigma.UUCP> <4750002@hpscdc.HP.COM> <47838@sun.uucp> <442@ontenv.UUCP>
Organization: York University, Toronto Canada
Lines: 37

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.