Jonathan Stone <jonathan@dsg.stanford.edu> wrote:

> I have changed the Subject: line to accurately reflect the subject of
> discussion, namely, Emmanuel's attempts to write a multicast application
> which  achieves a network meltdown via multicast, in pursuit of an
> information-dissemination applicatoin.

Are you always that harsh on people that just come to fix something they
thought to be a problem?
=20
> 1.  You are Attempting to write a multicast application for
> dissemination of information.

Wrong: I wrote an application for disemination of information, and I'm
trying to increase performances.
=20
> 2.  You want the application to send at wire rate.
>=20
> 3. You deliberately wish the application to be non-rate-adaptive:
> fixed-rate, wire-speed.

Yes. The target situation is a LAN where communication are close to be
reliable. There are very few packet drops, and no congestion. When I
wrote the tool two years ago, I remember I giving a try to other already
existing tools (I don't recall what I tried exactly) but rate-limitation
mecanisms lowered performance enough so that I decided to quickly write
that tool.

The first version did not do multicast but broadcast, thus effectively
melting down the network. It was disseminating the data fast enough, at
the cost of making the LAN unusable for a short time. I moved it to
multicast after some time to fix that. With IGMP snooping enabled
switches, the machines not participating to the operation can still use
the network. =20
=20
> 6.  You mention several times that the sender must detect loss between
> its send() calls and the wire.  I see no mention of either ACKs or
> NACKs=20

There are NACK. Else a single packet drop would kill the transfer.
Packet drops are rare but not unexisting.

--=20
Emmanuel Dreyfus
Un bouquin en fran=E7ais sur BSD:
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org