我会欣赏现实世界的例子，我很乐意接受主观答案，即你最喜欢的多播协议，如果你能解释它的优缺点。
现实世界的例子：TIBCO Rendezvous。数据通过具有序列号的组播发送出去。检测到丢失的序列号的客户端发送多播组的消息“嘿，我错过了数据包12345”。服务器重新组播数据。如果客户端请求，服务器可以缓冲数据量。
问题：
想象一下，有一个客户端丢失了一半的数据包，还有100个健康的客户端。该客户端发送每个其他数据包的重发请求。服务器开始对其中一个健康的客户端造成足够的负载，从而开始丢弃数据包并请求重传。额外的负载从另一个健康的客户端开始请求重传。等等。拥挤崩溃的结果。
Tibco提供了一种解决方案，可以切断发送太多重发请求的用户。这使得单个用户更难以引起拥塞崩溃。
限制拥塞崩溃风险的其他解决方法是限制服务器愿意重新发送的数据量。
Tibco还应该在客户端和服务器中提供启用多播还是单播重传请求以及重传本身的启发式。他们没有(对于服务器，如果只有一个客户端在特定时间窗口中请求，您可以单播重传，如果服务器在重传的数据包中告诉您，您是唯一一个请求的客户端，您可以单播重传请求重传，并在将来单播请求)
从根本上说，您必须确定您希望确保客户获得数据的速度与拥塞崩溃的风险有多大。您将必须猜测分组丢弃的位置以及重传是否最有效地发送单播或多播。如果服务器了解数据，并且如果有更新的数据要发送(使重传无关)，则可以决定不发送重传，因此您比Tibco RV等框架更好。
有时理解数据可能导致错误的假设。例如，市场数据 – 当有更新的报价时，似乎首先可以不转发报价。但是后来你可能会发现订阅者保持一个报价历史记录，而不仅仅是追踪当前的报价。也许根据用户的不同，您可能会有不同的要求，有些客户端更喜欢单播TCP与组播。
在某些时候，您需要在服务器上作出任意决定，以便在重新传输或缓慢的客户端时缓冲多少数据。