真实世界的示例：TIBCO Rendezvous。
TIBCO Rendezvous使用多播发送带有序列号的数据。如果客户端检测到丢失的序列号，它会在多播组上发送消息“嘿，我错过了数据包12345”。服务器会重新多播该数据。服务器有一个可配置的缓冲区以防止客户端请求它时出现问题。
问题：
假设有一个单独的客户端，它会丢失一半的数据包，并且有100个正常的客户端。该客户端为每隔一个数据包发送一个重传请求。服务器开始导致健康客户端之一的负载足够大，以至于它开始丢弃数据包并请求重传。这造成的额外负载导致另一个健康客户端开始请求重传。如此循环下去，导致拥塞崩溃。
Tibco提供了一种解决方法，即切断发送过多重传请求的订阅者。这使得单个订阅者更难引起拥塞崩溃。
减少拥塞崩溃的另一个解决方法是限制服务器愿意重传的数据量。
Tibco还应在客户端和服务器中提供启发式方法，以确定重传请求和重传本身是多播还是单播。他们没有这样做。(对于服务器，如果只有一个客户端在某个时间窗口内请求，则可以将重传请求单播；对于客户端，如果服务器已经在重传的数据包中告诉您 - 只有您一个人请求重传，请在未来进行单播)
从根本上说，您必须在保证客户端接收数据的强度和拥塞崩溃风险之间做出决策。您必须猜测数据包丢失的位置以及重传最有效的方式是单播还是多播。如果服务器理解数据并且可以决定是否发送重传数据（因为有更新的数据可发送，使得重传变得无关紧要），那么您的情况要比Tibco RV等框架好得多。
有时理解数据会导致错误的假设。例如，市场数据 - 起初可能认为不重新传输报价是可以接受的，但后来发现订阅者正在保留报价历史记录，而不仅仅是跟踪当前报价。也许您可能根据订阅者的不同要求有所不同，一些客户将更喜欢单播 TCP 而不是多播。
在某些时候，您需要在服务器端进行任意决策，以确定在重传或缓慢客户端情况下需要缓存多少数据。
继TIBCO之后，PGM协议是一种可靠的开放标准组播协议，具有许多优化功能，可在网络元素加速的情况下高效地工作在非常大的规模上。PGM由TIBCO和CISCO开发，并且是TIBCO Rendezvous下面的一个可选协议，其默认协议为TRDP，两者设计非常相似。
您可以计算PGM的理论效率，如此处所列。
http://code.google.com/p/openpgm/wiki/PgmPerformance
不幸的是，现实世界中的网络设备、网卡和一般计算机架构的性能远低于理论最大值。
比特流！
不开玩笑。你可能想要了解一下。
UDP对于多播很有用，但它不能提供你所寻找的保证 - BitTorrent将要求你从原始源传输超过一个完整副本，但它仍然相当高效并提供有用的保证，特别是考虑到每个“块”数据传递时所做的校验和有多少。
这是一个开放性的研究问题；虽然有商业解决方案可用，但价格昂贵。祝好运。
如果你真的想要可靠地同时向多个客户端传输数据，我认为你应该考虑一下流控制传输协议作为UDP / 多播的替代方案。
