Geek Answers Handbook

UDP Multicast Methods

I am preparing my university exam, and last year one of the questions was “how to make UDP multicast” (for example, tcp, retransmission of lost packets)

I thought of something like this:

  • Server sends multicast using UDP

  • Each client sends an acknowledgment of these packets (using TCP)

  • If the server understands that not everyone receives packets, it redirects multicast or unicast to a specific client

The problem is that there may be one client that usually lost packets and a push server.

It's good?

+5
source share
2 answers

To make UDP reliable, you need to handle a few things (i.e. implement it yourself).

Connection Handling: The connection between the send and receive process may be disconnected. Most trusted implementations typically send keep-alive messages to maintain a connection between the two ends.

Sequence: Messages must be split into pieces before being sent.

Confirmation: After receiving each message, it is necessary to send an ACK message to the sending process. These ACK messages can also be sent over UDP, not necessarily over UDP. The receiving process can understand that the message has been lost. In this case, it will stop delivering messages from the waiting queue (the message queue in which the received messages are stored, this is like a waiting room for messages) and a request for retransmission of the missing message.

Flow control: Cancel data sending based on the capabilities of the receiving process for data delivery.

Usually there is a process group leader. Each of these groups usually has a leader and a view of the whole group. This is called virtual synchronization.

0
source

Each client sends an acknowledgment of these packets (using TCP)

Sending an ACK for each packet and using TCP for this does not scale for a large number of receivers. Using a NACK based scheme is more efficient.

Each packet sent from the server must have a serial number associated with it. When customers receive them, they track which missed numbers were missed. If packets are skipped, a NACK message can be sent back to the server via UDP. This NACK can be formatted as a list of sequence numbers or a bitmap of received / not received sequence numbers.

If the server understands that not everyone receives packets, it redirects multicast or unicast transmission to a specific client

When a server receives a NACK, it should not immediately forward the missing packets, but wait for a period of time, usually a multiple of GRTT (Group Round Trip Time - the largest round-trip time between a set of receivers). This gives time to accumulate NACK from other receivers. The server can then multicast the missing packets so that any missing clients can receive them.

If this scheme is used to transfer files as opposed to streaming data, the server can alternately send the file data to the passages. The full file is sent in the first pass, during which all received NACKs are accumulated, and packets that must be resent are marked. Then, in subsequent passes, only retransmissions are sent. This has the advantage that lower loss clients will be able to finish receiving the file, while higher loss receivers may continue to receive retransmissions.

The problem is that there may be one client that usually lost packets and a push server.

For very lossy clients, the server can set a threshold value for the maximum percentage of dropped packets. If a client sends a NACK back more than one threshold one or more times (how many times to the server), the server can refuse this client and either not accept its NACK, or send a message to this client, telling it that it has been dropped.

There are a number of protocols that implement these functions:

Relevant RFCs:

0
source

More articles:


All Articles