6

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 ?

dbush
  • 205,898
  • 23
  • 218
  • 273
Laoni
  • 61
  • 1
  • 2
  • I assume that the acknowledgment in step 2 involves actually connecting to the server? Also, step 3 is potentially endless, what if some client is on a *really* bad connection, or have a local firewall that silently drops packets. – Some programmer dude Jul 03 '15 at 06:07
  • I think that there isn't other option than connecting to the server in step 2. Yes, that's the problem with step 3. Is there any workaround ? – Laoni Jul 03 '15 at 06:19
  • The solution for number 3 is to either continue retrying infinitely, or simply give up with an error message after a certain number of retries. And if you want to use a TCP acknowledgment in step 2 then there's really no other way. – Some programmer dude Jul 03 '15 at 06:23
  • it's my idea to use TCP in step 2, so maybe it's wrong. I think that using udp to acknowledgement exacerbate problems – Laoni Jul 03 '15 at 06:31
  • 1
    I think the question has already been answered: [pragmatic general multicast](https://code.google.com/p/openpgm/). Other than TCP, it uses NACK rather than ACK, which is more favorable with multicast. How would you handle ACKs for possibly 10,000 clients receiving your datagrams? NACKs are sent only when packet loss is detected, in conditions where multicast is available this is usually <1%. – Damon Jul 03 '15 at 10:20
  • It's not like TCP at all. You need to look this up. There is a whole IETF Worjing Group on reliable multicast, and quite a number of existing protocols such as TRAM. – user207421 Jul 03 '15 at 10:30

2 Answers2

4

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:

Community
  • 1
  • 1
dbush
  • 205,898
  • 23
  • 218
  • 273
0

To make UDP reliable, you have to handle few things (i.e., 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.

Andrei
  • 7,509
  • 7
  • 32
  • 63