Netcat broadcasting

Hi group,

I've got the following problem:
I want to find a way to use Knoppix to clone HD partitions via a network.
The combinations DD/Netcat and NTFSclone/Netcat do work finde, but I found
it's quite a strain on the network to have the complete HD image transferred
once to each client. I've read that netcat has a broadcasting option which,
I guess, would solve this problem (open a netcat listener on the
"Slave"-PCs and do a nc broadcast to all of the clients).
I have played around with the "-b" nc option but with no luck so far.
Any ideas or alternatives?

Thanks in advance

In the Usenet newsgroup comp.os.linux.networking, in article
<4352d1f0$0$21243$(E-Mail Removed)>, Riddic wrote:

>I want to find a way to use Knoppix to clone HD partitions via a network.
>The combinations DD/Netcat and NTFSclone/Netcat do work finde, but I found
>it's quite a strain on the network to have the complete HD image transferred
>once to each client.

We do our system installs over the network, and found somewhat similar
problems. Our solution was to have all "new" installs on an isolated
network. Reinstallations are usually done the same way, although it
can be done over the normal networks as this is not a common occurrence.

>I've read that netcat has a broadcasting option which, I guess, would
>solve this problem (open a netcat listener on the "Slave"-PCs and do a
>nc broadcast to all of the clients).

The main problem you run into is that broadcast (and multicast) are
not really interactive functions, so if there is a single bit error on
a transmission, the entire transmission is a bust, and the receiving
system is going to have to wait until the transmission is over, then send
a "I didn't get <mumble>, could you please send that again" message.
Multicast (not broadcast) has this capability.

>Any ideas or alternatives?

I'm not able to supply details, but we use an internally created ap (read
that as "proprietary", and NDA - sorry) that uses Multicast to deliver
nightly errata. The clients are semi-interactive in that they can request
retransmission of missed - garbled packets (if the other clients didn't
miss the packet, the retransmission is ignored due to sequence number
detection). See RFC1301 for further details on the concept. This is
normally run in the middle of the night as a cron job, but the few
times I've seen the packets, it hasn't been that bad. Admittedly, we're
rarely sending files over 20 Megs at a time and rarely over 150 Megs a
night, but I don't recall seeing that many retransmissions. The
application does need to be doing it's own parity/checksum/whatever
function to see that the received data is not corrupted, but it sure
speeds up the nightly updates.

Old guy