可靠实现UDP组播的方法 [英] Methods for implementing UDP multicast reliable
问题描述
我正在为大学考试做准备，去年的问题之一是如何使UDP多播可靠"(例如tcp，重新传输丢失的数据包)
I am preparing for my university exam and one of the question last year was " how to make UDP multicast reliable " ( like tcp, retransmission of lost packets )
我想到了这样的东西:
-
服务器使用UDP发送多播
Server send multicast using UDP
每个客户端(使用TCP)发送接收到该数据包的确认
Every client send acknowledgement of receiving that packets ( using TCP )
如果服务器意识到不是每个人都接收到数据包，它将向特定客户端重新发送多播或单播
If server realize that not everyone receive packets , it resends multicast or unicast to particular client
问题在于，可能有一个客户端通常会丢失数据包并迫使服务器重新发送.
The problem are that there might be one client who usually lost packets and force server to resend.
好吗?
推荐答案
每个客户端都使用TCP发送接收到该数据包的确认
Every client send acknowledgement of receiving that packets ( using TCP )
为每个数据包发送ACK并使用TCP进行发送，无法扩展到大量接收器.使用基于NACK的方案效率更高.
Sending an ACK for each packet, and using TCP to do so, is not scalable to a large number of receivers. Using a NACK based scheme is more efficient.
从服务器发送的每个数据包都应具有与其关联的序列号.当客户收到它们时，他们会跟踪丢失了哪些序列号.如果丢失了数据包，则可以通过UDP将NACK消息发送回服务器.此NACK可以格式化为序列号列表或已接收/未接收到的序列号的位图.
Each packet sent from the server should have a sequence number associated with it. As clients receive them, they keep track of which sequence numbers were missed. If packets are missed, a NACK message can then be sent back to the server via UDP. This NACK can be formatted as either a list of sequence numbers or a bitmap of received / not received sequence numbers.
如果服务器意识到并非每个人都接收到数据包，它将向特定客户端重新发送多播或单播
If server realize that not everyone receive packets , it resends multicast or unicast to particular client
当服务器收到NACK时，它不应立即重新发送丢失的数据包，而应等待一段时间，通常是GRTT的倍数(组往返时间-接收器组中最大的往返时间).这使它有时间积累来自其他接收器的NACK.然后，服务器可以多播丢失的数据包，以便所有丢失它们的客户端都可以接收它们.
When the server receives a NACK it should not immediately resend the missing packets but wait for some period of time, typically a multiple of the GRTT (Group Round Trip Time -- the largest round trip time among the receiver set). That gives it time to accumulate NACKs from other receivers. Then the server can multicast the missing packets so any clients missing them can receive them.
如果此方案用于文件传输而不是流数据，则服务器可以轮流交替发送文件数据.完整文件在第一遍发送，在此过程中，将累积接收到的所有NACK，并标记需要重新发送的数据包.然后，在随后的遍历中，仅发送重传.这样的好处是，丢失率较低的客户端将有机会完成文件的接收，而丢失率较高的接收者可以继续接收重传.
If this scheme is being used for file transfer as opposed to streaming data, the server can alternately send the file data in passes. The complete file is sent on the first pass, during which any NACKs that are received are accumulated and packets that need to be resent are marked. Then on subsequent passes, only retransmissions are sent. This has the advantage that clients with lower loss rates will have the opportunity to finish receiving the file while high loss receivers can continue to receive retransmissions.
问题在于，可能有一个客户端通常会丢失数据包并迫使服务器重新发送.
The problem are that there might be one client who usually lost packets and force server to resend.
对于损失非常高的客户端，服务器可以为丢失的最大数据包百分比设置阈值.如果客户端发回超过该阈值的NACK一次或多次(取决于服务器的次数)，则服务器可以丢弃该客户端，并且不接受其NACK或向该客户端发送消息以通知其已放下.
For very high loss clients, the server can set a threshold for the maximum percentage of packets missed. If a client sends back NACKs in excess of that threshold one or more times (how many times is up to the server), the server can drop that client and either not accept its NACKs or send a message to that client informing it that it was dropped.
有许多实现这些功能的协议:
There are a number of protocols which implement these features:
- UFTP - Encrypted UDP based FTP with multicast (disclosure: author)
- NORM - NACK-Oriented Reliable Multicast
- PGM - Pragmatic General Multicast
- UDPCast
相关RFC:
- RFC 4654-TCP友好型组播拥塞控制(TFMCC):协议规范
- RFC 5401-组播否定确认(NACK)构建块
- RFC 5740-面向NACK的可靠多播(NORM)传输协议
- RFC 3208-PGM可靠传输协议规范
- RFC 4654 - TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification
- RFC 5401 - Multicast Negative-Acknowledgment (NACK) Building Blocks
- RFC 5740 - NACK-Oriented Reliable Multicast (NORM) Transport Protocol
- RFC 3208 - PGM Reliable Transport Protocol Specification
这篇关于可靠实现UDP组播的方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
