实现UDP组播可靠的方法

Question

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 )

I thought about something like this :

1. Server send multicast using UDP

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

3. 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.

Is it good ?

Answer 1

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

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.

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

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.

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.

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

Relevant RFCs:

• 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

Answer 2

To make UDP reliable, you have to handle few things (ie, implement it yourself).

Connection handling: Connection between the sending and receiving process can drop. Most reliable implementations usually send keep-Alive messages to maintain the connection between the two ends.

Sequencing: Messages need to split into chunks before sending.

Acknowledgement: After each message is received an ACK message needs to be send to the sending process. These ACK messasges can also be sent through UDP, doesn't have to be through UDP. The receiving process might realise that has lost a message. In this case, it will stop delivering the messages from the holdback queue (queue of messages that holds the received messages, it is like a waiting room for messages), and request of a retransmission of the missing message.

Flow control: Throttle the sending of data based on the abilities of the receiving process to deliver the data.

Usually, there is a leader of a group of processes. Each of these groups normally have a leader and a view of the entire group. This is called a virtual synchrony.