gjm@ihnp4.UUCP (11/01/83)
Steve Bellovin's pathalias program can take nearly any information into
account. The problem with network paths is administrative as opposed to
technical.
(1) The form for the information maintained has to be standardized.
(2) Dedicated effort is required to keep local information up to date.
(3) A distribution mechanism is needed to make the information available
to all administrators.
I've had some experience for a similar service to over 200 SA's
representing over 500 systems in AT&T and the old Bell System. Anyone
willing to tackle 2 to 3 times that number across company, geographic,
and political boundaries has my best wishes.
On a matter of trivia, Gene Spafford says: (For example, sites like
ihnp4, allegra, and decvax connect to hundreds of sites for mail, but
they couldn't possibly handle news for even a tenth of their
connections.)
ihnp4 has over 80 netnews connections and advertizes over 600 mail
connections, so the number of news connections is greater than a tenth
of its (mail) connections.
Gary Murakami
Bell Labs - IH
ihnp4!gjmmark@cbosgd.UUCP (Mark Horton) (11/02/83)
ihnp4 has over 80 netnews connections and advertizes over 600 mail connections, so the number of news connections is greater than a tenth of its (mail) connections. Yeah, but ihnp4 has this huge IBM system to send the news out to the 80 neighbors! ihnp4 is a special case and no other machine on Usenet is quite like it.
fair@dual.UUCP (Erik E. Fair) (11/03/83)
Mark,
Not many mailers will handle INTERNET format addresses. There are two
of which I am aware:
1) Berkeley sendmail
2) hacked nmail
Sendmail has one fundamental limitation: the INTERNET format only works
for those sites that the local host talks to directly. So, for example,
if I wanted to reply to something that someone at gatech wrote, I would
have to generate the path myself, since dual does not talk directly to
`gatech'.
Nmail is an interesting solution, a look up table. However, as Gene
Spafford pointed out, there is no measure of connection reliability.
This is one of the problems I will have to contend with in the database
that I keep, but for now, I'm having a fun time just trying to collect
the information at all.
The format that the vast majority of sites are choosing is !INTERNET,
and so we get letters bouncing all over here and begone. As an aside,
is anyone working on making better USENET connections overall? I got a
reply to this article from `mcvax' in Amsterdam, and he sent me (along
with some comments), the path that the article took to get to `mcvax'.
The article bounced across the continental U.S. THREE TIMES before
making the leap across the Atlantic. The interesting point is that
`mcvax' is not more than 4 news hops away from dual.
more fuel for the fire,
Erik E. Fair {ucbvax,amd70,zehntel,unisoft}!dual!fair
Dual Systems Corporation, Berkeley, Californiamark@cbosgd.UUCP (11/03/83)
The point is that netnews is not the proper place to implement Internet mail addressing. If it's going to be done, it should go in the mail system, not the news system. News need merely pass Internet addressses through and allow that they be used. Sendmail as done at Berkeley does not support Internet addressing on UUCP, unless there is a direct connection. There does exist code to interface to sendmail to do UUCP routing, and we run it here on cbosgd. The problem is that there is currently no official well-supported UUCP connection database to run this software from. There are good reasons to hope that this situation will be remedied within 6 months or so. Of course the news paths from dual are ridiculously long! You go through ucbvax, which has chosen to be in the far off sticks of Usenet. The only way news can escape from dual is to go through the path dual -> ucbvax -> ucbcad -> tektronix, at which point it might go to uw-beaver, decvax, or zehntel.
dave@utcsrgv.UUCP (Dave Sherman) (11/03/83)
Contrary to Erik Fair's statement, some sites do optimize news paths
that comes through them. Decvax is one. I believe uw-beaver may
be another. I first found out that decvax talks to utcsrgv
because mail directed via utzoo was called in directly to us from decvax.
I agree that everyone should use paths which are different from the
paths that news took to get to them. When you use 'r' in readnews,
you get a file whose first line you can edit to amend the header.
EVERYONE who is replying to articles should know how to get to
a few of the basic sites. If you check, you will probably find
that YOUR site talks to ihnp4, and perhaps allegra, decvax, linus,
decwrl, utcsrgv, ucbvax, floyd, utzoo, uw-beaver, or cornell. If not,
you're only a hop or two away. USE THE SHORT PATHS.
(Incidentally, all of the above sites except ucbvax talk to utcsrgv,
and ucbvax talks to the rest of them...)
Dave Sherman
(thanks all you nice backbone people)
--
{allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsrgv!davefair@dual.UUCP (Erik E. Fair) (11/04/83)
Did you know that ucbvax is only six hops away from the furthest site
on the entire net? This interesting statistic was generated in about 4
hours of real time on a Vax-11/750 and lots of INGRES inquiries. I
generated the whole tree (i.e. the shortest paths from ucbvax to
everywhere) and found this out. I'm sure my database doesn't completely
reflect the whole net at any given moment. It's just too dynamic, and
too big to keep my database completely validated. However, since I am
insane, I try.
Did you know that people routinely use 10 and 15 hop addresses that
take letters bouncing from the east coast to the west coast and back
again? News just provides a return path which reflects from whence an
article came. It is, by nature, not optimal since the net works by
`pass it on'. Just this evening I got a letter from one of the alux?
sites which bounced all over Holmdel, NJ, and Murray Hill, NJ then
through Naiperville, IL, and finally through decvax (Merrimack, NH) to
decwrl, amd70 and here. I replied to him with a three hop letter from
here to ucbvax to ihnp4 and finally to alux?. I have seen stuff from
the East coast of the US bounce through Europe before getting here.
Now, imagine how much that clutters up the network.
(pregnant pause)
The USENET (and the larger UUCP network) have exactly the same problems as
the ARPANET, but greatly magnified by three things:
1) *Many* more sites (although,
the Internet is growing fast these days...)
2) *Much* slower network speed.
(i.e. all basic information propagates more slowly)
3) Lack of enforceable control.
(i.e. we can't beat a site into running 2.10.1, or anything
else vaguely sane, once the site can speak uucp)
The ARPANET has solved their routing problems by burying it in table
driven software. The attendant administrative problem is to get all of
the host liaisons to update their host tables when a new site gets
added. Also software updates and validation are a big pain. The
NCP -> TCP/IP conversion was lots of fun for the people at the Network
Information Center, and ARPA itself. (for those who don't know,
ARPANET underwent a network wide protocol conversion on January 1, 1983
and *many* sites just dropped off the network because they weren't
ready, after two years of warning! Most of them are back by now)
Our problem is that the network requires explicit routing paths, and the vast
majority of network users don't keep the routing tables around (or in their
heads for that matter!) and compounding that, neither news nor the intervening
sites (mail forwarders) attempt any optimization of paths. A very simple
lookup with `uuname' and examination of news mail reply for sites that the
local site talks to, could simplify things immensly, and it has the added
benefit of encouraging more links to different places. (i.e. the more
places your local site talks to, the better this sort of optimization becomes).
Now I realize that uuname only lists the sites that you talk to and not
when or how often, but it's a start, and it doesn't force maintainance of a
new table just for news (although that might be an option).
Well, news maintainers? Want to add a quick hack to recmail for the next
distribution?
In the interest of keeping this short (!!), I will say no more, other than
to quote Heinlein: "If this goes on..."
Comments to the net please. I got enough mail cluttering my mailbox, pleading
for an answer.
quixotically yours,
Erik E. Fair {ucbvax,amd70,zehntel,unisoft}!dual!fair
Dual Systems Corporationfair@dual.UUCP (Erik E. Fair) (11/04/83)
Actually, we couldn't get ucbvax to feed us news. We get it from amd70.
the path that I get return mail by looks mostly like this:
amd70!decwrl!decvax!place!place...
We also feed locally generated articles to zehntel, and I have seen
one response to that, but both places are (relatively) in the sticks
USENET wise.
BTW, Mark, if you could cause ucbvax to feed us, I would appreciate it.
amd70 is in Sunnyvale, in the 408 area code, thus it is a long distance
call. ucbvax is local, since we're about two miles away from Campus.
Have they got batching up yet?
Erik E. Fair {ucbvax,amd70,zehntel,unisoft}!dual!fair
Dual Systems Corporation, Berkeley, Californiajohn@garfield.UUCP (John McCarthy) (11/05/83)
I have also found the return paths for news articles to be
bizarre. Here is a man(1) page for a program that at least helps.
I'm submitting this now to solicit comments on improvements I could
make before I submit the sources to net.sources. It uses the data
collected from the net for the nmail(1) program so you'll need that
software to use this. I think it was submitted over the net a while
ago.
With news 2.10 you can use vi(1) to edit your headers. This makes
it easy to fix up return paths. I only wish you could send the headers
to your own mail+editor. This way I could fully automate the process by
running the headers through cvtpath before calling the editor (or even after).
The way 2.10 is set up now (at least our version) the user defined mailer
is used only with the 'rd' and 'fd' commands and it isn't sent
the References: line. I don't think the subject is even sent, but I
could easily be wrong on this. (Hmm maybe if I define the EDITOR to
be a program that runs vi(1), then optimises the result and returns
it to news? Kludgy but it might work) Note that my use of only vi(1)
in examples is not a sign of prejudece against other editors with these
capabilities. I just don't know how it's done with EMACs version xxx
by yyy, etc.
Anyway, I will wait about two weeks for replys. Then I'll make
any changes I think are necessary and send a distribution over net.sources.
PLEASE reply by mail if at all possible (We are directly connected to
both ihnp4 and allegra).
John McCarthy.
P.S. Just an aside. For those people who don't like path optimisers or
can't keep reasonable connection databases, removing loops in paths
would at least help. This wouldn't require any more info. than that
contained in the return path itself.
us.UUCP: ucbvax!allegra!garfield!john
can.UUCP: utcsrgv!garfield!john
MA BELL: (709) 737-8330
SNAIL: Computing Services;Memorial University;St. John's, NFLD.;A1C 5S7
===========
CVTPATH(1) UNIX Programmer's Manual CVTPATH(1)
NAME
cvtpath - find and optimise UUCP paths
SYNOPSIS
cvtpath path1 path2 ...
cvtpath < file
DESCRIPTION
Cvtpath is a program to find and optimise UUCP paths to
other computer systems. It uses a database created for the
nmail(1) program to find the paths. Systems not in the
database are handled gracefully, the path to the first sys-
tem that is in the database is optimised.
Cvtpath prints the best path for each argument on the stan-
dard output. If no arguments are given, the standard input
is read and each path found is optimised. Paths are defined
as any blank delimited word containing and exclamation (!)
character. All other input is output exactly as is. In
vi(1) the commands:
!10!cvtpath
will optimise the next ten lines in the file. This makes it
easy to optimise mail headers created by the 'r' command of
readnews(1).
FILES
/usr/lib/nmail.paths - UUCP path database
/usr/lib/pathdb.dir
/usr/lib/pathdb.pag - dbm(3) version of path database
SEE ALSO
nmail(1), readnews(1)
AUTHOR
John McCarthy (garfield!john)
BUGS
It does not optimise Internet addressing. The definition of
a path may be naive, and there is no way to escape an excla-
mation point. On systems without the dbm(3) database rou-
tines it is slow. The interface with news could be better.
Printed 11/4/83 MUN 1rees@apollo.UUCP (Jim Rees) (11/07/83)
I wrote the mail router in use at the uw-* sites. I think it does the "right" thing most of the time. When mail arrives via uucp, each of the sites in the path are examined, from farthest to nearest, to see if we talk to them directly. If so, the path is truncated at that point and the mail sent on to that site. For example, if mail comes in addressed to "foo!bar!baz!joe", and we talk directly to site "bar" (as well as to "foo"), then the message will go off to "bar" addressed to "baz!joe". This can only result in a shorter path, so loops are avoided. I stole the idea for this from Honeyman at allegra (now at Princeton). I think this scheme is in use there and at ihnp4.