java实现udp组播,可靠实现UDP组播的方法

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 :

Server send multicast using UDP

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.

Is it good ?

解决方案

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:

Relevant RFCs: