Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!cornell!gvax!jqj
From: jqj@gvax.cs.cornell.edu (J Q Johnson)
Newsgroups: net.unix-wizards
Subject: Re: simultaneous file transfer on ethernet (SUN's)
Message-ID: <470@gvax.cs.cornell.edu>
Date: Mon, 25-Aug-86 07:59:12 EDT
Article-I.D.: gvax.470
Posted: Mon Aug 25 07:59:12 1986
Date-Received: Tue, 26-Aug-86 05:04:25 EDT
References: <6@cvbnet.uucp>
Reply-To: jqj@gvax.cs.cornell.edu (J Q Johnson)
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 21

The author of the original article proposes use of broadcast/multicast (on
networks that support it) as a way of achieving multiple parallel file
transfers.  The problem with this scheme, obviously, is that there is no
simple way to achieve reliability (though see various papers on "reliable
broadcast" by Ozalp Babaoglu et al).  Most file transfer protocols use
end to end ack/nack to make sure the data got there, which assumes the
sender knows who is receiving the data.

A multicast-based ftp is not impossible, but it certainly doesn't match
the communications model of any of the popular existing protocol families
(tcp/ip, sna, decnet, osi, xns, etc.).  TCP/IP didn't even standardize
the value of the broadcast \fIaddress\fP until recently!

Note that most existing broadcast applications on Ethernets assume
unreliable broadcast, and are generally used for sending status information
(or requests for information).  In almost all cases, the amount of 
information to be transferred is limited to a single packet.

Conclusion:  it's a good topic for research, but don't expect anyone to
implement such a beast in the near future.  And don't ever expect to
see it layered on TCP/IP.