simultaneous file transfer on ethernet (SUN's)

[Guy Harris]

>     I also, using the multi-cast bit, should be able to set up a table
>     of nodes that I wish to distribute the program to.

Except that the Sun driver for the "ie" interface doesn't understand
multicasts.  You'd have to change that driver, provide "ioctl" calls to set
the multicast address group, and provide a way, in whatever protocol you
used, to specify that a packet is to go to a multicast group.

> 2.) Some user-level programs already do something similar to what
>     I want.   For instance, "wall" will broadcast a message to nodes
>     on your network.

No, it won't.  The "rwall" command will send messages to other machines;
however, it does not "broadcast" them, in the sense that it uses Ethernet
broadcast facilities for this.  when discussing networks.  If it is asked to
send messages to a set of machines, it does so by running through an
enumeration of those machines and sending to them one at a time.

> I know NFS allows mounting of an application to nodes and simultaneous
> access of that application - but that is not what I want.  I want to
> distribute to stand-alone machines as well as file servers new copies
> of an application once a week and each rcp or "dread the thought"
> cartridge taping can consume 1/2 hour per node.

You may, in this case, want to have the stand-alone machines get the
application via NFS.

> I would like to be able to say something like:
> 
> distribute -g <tablefile> <application> 
> 
> where -g is the option for group and tablefile is the database that
> contains a list of nodes with names or internet addresses

Even if IP supported multicast groups, this would not be straightforward.
You can't assign a host to a multicast group; that host has to add
*itself* to the multicast group.  As such, you'd have to start by telling
the hosts in that list to join a particular multicast group (you'd also have
to either 1) reserve a multicast group for this or 2) find some way of
finding an unused group and choosing it).

I think there may be some RFCs discussing the use of multicast addresses in
IP, but I doubt that there are any standard implementations of this for
UNIX.  At best, they're probably experimental.  At worst, they don't exist.
There are a lot of complicated issues involved in putting multicast support
into IP.

Of course, as stated before, you'd have to whack on the networking code
quite a bit to teach it about multicast addresses, anyway.

> Can it be done?

Maybe, if you're willing to learn a lot about IP, Ethernet, and the 4.2BSD
networking code, and make *lots* of changes to it.  I don't guarantee that
it'd be possible even then.

> When "wall" does a broadcast - is it simultaneous to all nodes or
> consecutive?

As I mentioned above, "wall" doesn't do broadcasts at all; since "rwall"
doesn't do them as Ethernet broadcasts, they are consecutive.  (No, "rwall"
doesn't fork off N processes, one per machine.)

> What kind of error checking do I have to do for testing that
> the program was successfully transmitted without losing packets
> or corrupting packets - at source or destination?

Lots.  TCP doesn't understand broadcasts, much less multicasts, and can't
really be made to.  As such, you'd have to provide your own flow control and
error recovery.

As Charles Hedrick pointed out, this won't work well (if at all) if you want
to update hosts that aren't on the same Ethernet, either.

I think the best advice is "try something else".
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.com (or guy at sun.arpa)