Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!topaz!hedrick
From: hedrick@topaz.RUTGERS.EDU (Charles Hedrick)
Newsgroups: net.unix-wizards
Subject: Re: simultaneous file transfer on ethernet (SUN's)
Message-ID: <5604@topaz.RUTGERS.EDU>
Date: Sun, 24-Aug-86 22:30:13 EDT
Article-I.D.: topaz.5604
Posted: Sun Aug 24 22:30:13 1986
Date-Received: Sun, 24-Aug-86 23:33:38 EDT
References: <6@cvbnet.uucp>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 54

The original article asks whether it is feasible to update software on
multiple systems by using a broadcast protocol.  This would save you
from having to do separate copies to each.  Anything is possible to do
with enough design work, but let me mention two serious problems.

First, the Ethernet is not a reliable medium.  This means that any
individual packet may be dropped.  All protocols currently used to
send files include some sort of acknowledgement that the packet really
got there.  If an ack is not received, the sender resends the packet.
This is true of FTP, rcp, and NFS, though the actual details of the
protocols are different for NFS and the other two.  So a broadcast
distribution protocol would have to keep a list of the sites that are
expected to be receiving, and keep resending each packet until it has
gotten an ack from every receiver.  Since the acks would all be sent
at the same time, you would have guaranteed collisions on the
Ethernet.  Probably you would want some sort of randomized delay
before sending the ack.  This would be a nontrivial design problem,
and probably there would be other implications that I have not
noticed.  But an experienced protocol designer could probably solve
the problem.

You imply that you are going to be updating hundreds of Suns.  I would
be somewhat wary of the idea of hundreds of Suns on a single Ethernet.
When we asked Sun about this, they recommended no more than 50 
diskless Suns on a single Ethernet.  Our measurements suggest that
this number is about right.  Of course if the machines are not
diskless, more should be possible.  But there is a limit.  If you have
hundreds of machines, they are probably going to be on more than one
Ethernet, with gateways.  Broadcasts do not go through gateways,
unless special provisions are made.  This is a good thing.  It
protects networks from other networks where a machine has decided to
start spraying the network with high-speed broadcasts (a failure mode
that is not uncommon when you are playing with experimental network
software).  There are also problems in making sure that loops don't 
occur.  If a gateway forwards broadcasts from one interface to the
other, any very interesting topology will end up with broadcasts
looping around the network.  These problems can be solved, and indeed
there is an RFC describing multi-network broadcasts, but you should
realize that there are design issues involved with broadcast protocols
that involve more than one Ethernet.

My suspicion is that this is not worth doing.  I suggest instead using
a branching tree distribution.  I.e. your master sends to 10 machines
and each of them to 10 more, or something like that.  Note that the
Ethernet should be able to support a number of simultaneous transfers,
as long as they are not broadcasts.  The limit on network bandwidth
for most machines (including Suns) is the machine's own Ethernet
hardware and software.  The fastest real transfers I have seen are
1MBit/sec, and even that requires special care.  200Kbit/sec is more
normal.  Thus the Ethernet should be able to support a reasonable
number of simultaneous copies, as implied by the branching tree
model.  Collisions would not be the problem here that it would be
with the broadcast scenario, since the various copies would quickly
lose any synchronization that they might have.