First a caveat:
Multicast (resp all UDP based transport) by itself has no flow control, no congestion avoidance mechanisms, no ways to retransmit lost packets, and no inherent receive buffer scaling, as TCP offers them. Delivering large files (~10Gbytes) might call for some of these mechanisms, to ensure that eventually, the file is complete and uncorrupted at the remote end.
With multicast, the applications must compensate for many things they would not have to care about if the transfer were done with TCP.
- The sending application must make sure not to oversubscribe any link along the path
- The receiving application must make provisions to detect missing or
corrupted packets
- Both sender and receiver must make provisions to compensate for lost packets, this might turn out to be "expensive" on the software side. [1][2][3]
And now for the actual answer:
To cover for different bandwidth of different receivers: For each bandwidth level, use a seperate Multicast group and adjust sending rates accordingly.
Also: Be sure to check if the receivers are capable of ingesting, checking, reordering (and writing to disk) such large streams of UDP traffic. Remember: UDP does not have the "native" receive buffer scaling that TCP has. More than once (I'll admit: in the past) I've been seeing IP stacks that bailed out at ~130Mbit/s of UDP traffic, but were able to pump >800Mbit/s of TCP.
And finally:
It is expensive (in terms of programming/application design and network infrastructure) to use multicast to deliver data in a bit-complete, loss-free and reliable fashion. If these are a requirement, you should make sure that you cannot achieve the same goal with a well-designed solution based on unicast and TCP, possibly with some preloaded caching servers near the clients.
Mutlicast is good for financial market data, video streams, audio streams, where the occasional lost packet is "just as well", possibly compensated for by the video/audio codec on the receiver.
[1] for example: by sending the same stream with one mcast group address "A", across one network path, and the same stream with a mcast group address "B", across a different network path (might require pretty advanced multicast routing setup). At the application level, packets or data chunks are sequentially numbered and checksummed. The receiver subscribes to both groups, ingests both streams and does a logical comparison of all data chunks received before writing one good chunk to disk.
[2] other possibility: using a single group (per bandwidth class), each chunk is multicasted 3 times. Receivers have enough temporary storage to receive each chunk three times and logically combine one good chunk to write to disk.
[3] third possibility: since chunks should be numbered/checksummed anyway, clients can detect missing/incomplete/corrupted chunks and re-request them via unicast; of course, this needs a service on the server and a unicast capable client on the receiver, and it needs proper preparation of the data to be sent (segmentation into suitably sized chunks, sequence numbering, checksumming).