tcp - UDP组播可靠的实现方法

标签 tcp udp multicast reliable-multicast

我正在准备我的大学考试,去年的问题之一是“如何使 UDP 多播可靠”(如 tcp,丢失数据包的重传)

我想过这样的事情:

  1. 服务器使用UDP发送组播

  2. 每个客户端发送接收该数据包的确认(使用 TCP)

  3. 如果服务器意识到不是每个人都收到数据包,它会向特定客户端重新发送多播或单播

问题是可能有一个客户端经常丢失数据包并强制服务器重新发送。

好吃吗?

最佳答案

Every client send acknowledgement of receiving that packets ( using TCP )

为每个数据包发送一个 ACK​​,并使用 TCP 这样做,不能扩展到大量的接收者。使用基于 NACK 的方案效率更高。

从服务器发送的每个数据包都应该有一个与之关联的序列号。当客户收到它们时,他们会跟踪遗漏了哪些序列号。如果数据包丢失,则可以通过 UDP 将 NACK 消息发送回服务器。此 NACK 可以格式化为序列号列表或已接收/未接收序列号的位图。

If server realize that not everyone receive packets , it resends multicast or unicast to particular client

当服务器收到 NACK 时,它不应立即重新发送丢失的数据包,而是等待一段时间,通常是 GRTT(组往返时间——接收组中最大的往返时间)的倍数。这使它有时间积累来自其他接收器的 NACK。然后服务器可以多播丢失的数据包,这样任何丢失它们的客户端都可以接收到它们。

如果此方案用于文件传输而不是流式数据,则服务器可以轮流发送文件数据。完整的文件在第一次发送时发送,在此期间累积收到的任何 NACK 并标记需要重新发送的数据包。然后在随后的传递中,只发送重传。这样做的好处是,丢失率较低的客户端将有机会完成接收文件,而丢失率较高的接收方可以继续接收重传。

The problem are that there might be one client who usually lost packets and force server to resend.

对于丢失率非常高的客户端,服务器可以为丢失数据包的最大百分比设置一个阈值。如果客户端发回超过该阈值一次或多次(多少次由服务器决定),服务器可以丢弃该客户端并且不接受其 NACK 或向该客户端发送消息通知它它是掉线了。


有许多协议(protocol)实现了这些功能:

相关 RFC:

关于tcp - UDP组播可靠的实现方法,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/31199565/

相关文章:

java - MulticastSocket 中 joinGroup() 的用途

sockets - NSInputStream 无法从 TCP 连接读取 [TCP-Server]

networking - 如果 UDP 不可靠,为什么在传输层使用它

sockets - 如何在多宿主服务器的非默认接口(interface)上接收多播数据

c - sendto 函数出错

linux - 在 Linux 内核中为传输协议(protocol)注册协议(protocol)处理程序

asp.net - 多播 IP 地址的正则表达式

sockets - 是否可以使用 TCP 或 UDP 中继 UDP 或 TCP 数据;即混合协议(protocol)?

c# - .NET TCP 服务器稳定性问题

c - 建立tcp连接时给套接字的地址是什么?