simultaneous file transfer on ethernet (SUN's)

[guy at sun.UUCP]

> (Explanation that TCP guarantees packet delivery, but does not support
> broadcast, while UDP supports broadcast but doesn't guarantee packet
> delivery.)

> 	As you can probablly guess, if you choose to broadcast your
> updates to all your Sun workstations, you run the risk of randomly 
> dropping packets or losing bits of information in other ways.

Well, you *could* have the receiving hosts send back acknowledgments when
they received the broadcast packets.  This would be an excellent way to melt
down an Ethernet, though, given the number of hosts that would receive the
broadcast packet.  The sending host would also have to know *all* the hosts
the broadcast would go to, in order to know whether it got all the
acknowledgments it should.  It would also have to know what to do if it
didn't get acknowledgments from all the hosts; should it retransmit only to
the hosts that didn't get it (if 75% of them didn't get it, this could flood
the Ethernet) or to all the hosts.  In addition, the code on the receiving
end would have to be able to deal with packets received out of order, or
duplicate packets (especially if the response to negative or missing
acknowledgments is a broadcast retransmission).

> 	My reccommendation is to use NFS, as it was designed for
> precisely your situation.  (The original posting didn't state why the
> option was ruled out.)  If that option isn't acceptable, the next best
> option is to write a shell that sequentially rcp's the file to every
> node individually.  (RCP uses the TCP/IP protocol; it's no dummy!)

And NFS uses UDP/IP.  NFS operations return a success/failure indication
and, if a failure, an error code; this return message acts as the
acknowledgment.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.com (or guy at sun.arpa)