Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-adm!brl-smoke!smoke!wayne@ames-nas.arpa
From: wayne@ames-nas.arpa (Wayne Hathaway)
Newsgroups: net.unix-wizards
Subject: Re: RCP
Message-ID: <1755@brl-smoke.ARPA>
Date: Wed, 12-Mar-86 19:57:28 EST
Article-I.D.: brl-smok.1755
Posted: Wed Mar 12 19:57:28 1986
Date-Received: Sat, 15-Mar-86 18:26:44 EST
Sender: news@brl-smoke.ARPA
Lines: 50

Jim Cottrell comments on my description of our use of machine-id:

>I jumped to respond at this a bit too quickly I suppose.
>The `internet address' should be unique unless you are a gateway
>or connected to more than one network. In any case, picking the
>`dominant' network and using its internet address as `hostid'
>should work. 

We (or rather NASA Ames) is definitely a "more than one network"
situation, having essentially two backbones (a HYPERchannel and
an Ethernet).  Most hosts are (will be) on both, but a few are
on the Ethernet only and one (the Cray 2) is on the HYPERchannel
only.  They also have at least two hosts connected to an IMP.

Therefore even defining the "dominant network" becomes a problem,
especially when you consider that they really do want to be able
to (for example) use the Ethernet as a backup for the HYPERchannel
(and vice versa).  Of course, since there are only two networks
we could have just pretended each machine was really two different
machines and duplicated the mapping tables (for example, each host
would have two inward mapping tables, one from Ethernet host
128.102.4.14 and one (identical one) from HYPERchannel host
192.12.102.14, even though these two hosts are in fact the same
machine).  This would seem to have definite disadvantages in terms
of table space and maintenance, however.  For example, they just
recently changed the Ethernet from a Class C network to a portion
(to be a subnet) of an Ames-wide Class B network.  Using Internet
address instead of mid would have required changes to every hosts'
mapping tables.  As it was, the names did not change so the
name-to-mid mappings did not change; the only updating required
was to the various /etc/hosts files.  (And of course this could
have been avoided by the use of nameservers, but ...)

In addition, when you consider our design as a "total system,"
there are other arguments for mid.  For example, we have
implemented a batch job entry system (particularly for the Cray).
Unless otherwise directed, this system returns output "to the
originating machine."  But if you happened to submit your job
over the Ethernet, you would probably be upset if the system
refused to return your output simply because the Ethernet was
down, even though there was an alternate path available.  Again,
there are solutions which do not require mid; we just felt that
biting the bullet once and providing the capability to uniquely
identify each machine with a single number would be a winner.

But as they say, only time will tell.


Wayne Hathaway			wayne@ames-nas.arpa
Sterling Software/Informatics