protocols - 可靠多播的最有效协议(protocol)是什么？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

1年前关闭。




Improve this question




当发送者需要通过以太网以可靠的方式将相对大量的数据(例如每秒几兆字节)多播到同一子网上的适度数量的接收者(例如少于十二个)时，最有效的协议(protocol)是什么？可靠是指如果一个数据包丢失，协议(protocol)会确保它被重新发送，这样任何接收器都不会丢失数据。高效这个词很难定义，但是假设我们想要最大化吞吐量并最小化网络带宽，同时两端的 CPU 使用率适中。这仍然不是一个明确的定义，但这是我能想到的最好的定义。面向流或面向消息的协议(protocol)都是可以接受的。

我很欣赏现实世界的例子，我很乐意接受主观答案，即你最喜欢的多播协议(protocol)是什么，如果你能解释它的优缺点的话。

Answer 1

实际示例:TIBCO Rendezvous。

数据通过带有序列号的多播发送出去。检测到丢失序列号的客户端在多播组上发送消息“嘿，我错过了数据包 12345”。服务器重新多播该数据。服务器有一个可配置的数据量来缓冲，以防客户端请求它。

问题:

想象一下，有一个客户端丢弃了一半的数据包，还有 100 个健康的客户端。此客户端为每个其他数据包发送重传请求。服务器开始在其中一个健康的客户端上造成足够的负载，以致它开始丢弃数据包并请求重新传输。额外的负载会导致另一个健康的客户端开始请求重新传输。等等。拥塞崩溃的结果。

Tibco 提供了一种解决方法，即切断发送过多重传请求的订阅者。这使得单个用户更难导致拥塞崩溃。

限制拥塞崩溃风险的另一种解决方法是限制服务器愿意重新传输的数据量。

Tibco 还应该在客户端和服务器中提供关于是多播还是单播重传请求以及重传本身的启发式方法。他们没有。 (对于服务器，如果在某个时间窗口内只有一个客户端请求它，您可以单播重传，对于客户端，如果服务器告诉您 - 在重传的数据包中 - 您是唯一一个请求的客户端，您可以单播重传请求重传并请在将来单播请求)

从根本上说，您必须在您希望保证客户端接收数据的强度与拥塞崩溃的风险之间做出决定。您将不得不猜测数据包被丢弃的位置以及重传是最有效地发送单播还是多播。如果服务器理解数据并且可以决定在无论如何要发送更新的数据时不发送重传(这使得重传无关紧要)，那么您比 Tibco RV 等框架处于更好的位置。

有时理解数据会导致错误的假设。例如，市场数据——当有更新的报价时，最初似乎可以不重新传输报价。但稍后，您可能会发现订阅者正在保留报价历史记录，而不仅仅是试图跟踪当前报价。也许您可能有不同的要求，具体取决于订阅者，有些客户端会更喜欢单播 TCP 和多播。

在某些时候，您需要在服务器上任意决定要缓冲多少数据，以防重传或客户端缓慢。