Method for ensuring reliability of multicast transmission

Abstract

The invention discloses a method for ensuring the reliability of multicast transmission, which belongs to the technical field of local area networks, and comprises the following steps: step 1, a sender allocates a globally unique and progressively increasing serial number for each multicast data packet, and adds FEC (Forward Error Correction) redundant code in multicast data; 2, a receiver receives a multicast data packet, records continuous serial numbers through a sliding window, traverses the serial numbers in the sliding window, judges whether the serial numbers are continuous or not, if yes, it is judged that packet loss does not occur, the step 7 is executed, and if not, the step 3 is executed; 3, the receiver identifies redundant packets for receiving the multicast data packets according to the FEC redundant codes, counts the number of the redundant packets and judges whether the number of the redundant packets is larger than or equal to a threshold value or not, if yes, local error correction is carried out to recover data, then the step 7 is executed, and if not, the step 4 is executed. According to the method, the'confirmation storm 'is inhibited fundamentally, and the efficient balance of the network load is realized.

Description

Technical Field

[0001] This invention relates to the field of local area network (LAN) technology, and more specifically to a method for ensuring the reliability of multicast transmission. Background Technology

[0002] Many applications in local area network (LAN) environments require multicast for one-to-many transmission to save bandwidth. However, a drawback of multicast is the lack of built-in reliability mechanisms, such as acknowledgment and retransmission like TCP. To ensure multicast reliability, possible solutions include acknowledgment mechanisms, retransmission strategies, and error detection. However, in a multicast environment, each receiver needs to acknowledge the message, which can lead to an acknowledgment storm (ACK implosion), where a large number of acknowledgment messages are returned to the sender, causing network congestion. Therefore, a mechanism must be designed to avoid this situation.

[0003] Based on this, the present invention designs a method to ensure the reliability of multicast transmission in order to solve the above problems. Summary of the Invention

[0004] In view of the above-mentioned shortcomings of the existing technology, the present invention provides a method to ensure the reliability of multicast transmission.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A method for ensuring the reliability of multicast transmission includes the following steps: Step 1: The sender assigns a globally unique and incrementing sequence number to each multicast data packet and adds FEC redundancy coding to the multicast data; Step 2: The receiver receives multicast data packets, records consecutive sequence numbers through a sliding window, traverses the sequence numbers in the sliding window, and determines whether the sequence numbers are consecutive. If the determination is yes, no packet loss has occurred, and proceed to step 7; if the determination is no, proceed to step 3. Step 3: The receiver identifies redundant packets in the received multicast data packets according to the FEC redundancy coding, counts the number of redundant packets, and determines whether the number of redundant packets is greater than or equal to the threshold. If it is, the receiver performs local error correction and data recovery, and then executes Step 7. If it is not, the receiver executes Step 4. Step 4: Start the random backoff timer, request response data from neighboring nodes, and determine whether response data from neighboring nodes is received within the backoff time. If yes, proceed to step 5; if no, proceed to step 6. Step 5: Send a NACK message to the sender. The sender collects NACK messages and counts the number of requests with the same sequence number within a fixed buffer period. When the count reaches the trigger value within the fixed buffer period, Step 6 is executed immediately. When the fixed buffer period expires, requests with the same sequence number are merged, and Step 6 is executed again. Step 6: Send a retransmission data command to the sender. Upon receiving the retransmission data command, the sender retransmits the multicast data packet to the receiver, updates the receive window, and then executes Step 7. Step 7: The application layer receives multicast data packets and processes them normally.

[0006] Furthermore, the threshold is 15%.

[0007] Furthermore, the fixed cache period is 50ms.

[0008] Furthermore, the trigger value is 5 times.

[0009] Furthermore, the specific steps are as follows: Step 41: Start the random backoff timer; Step 42: Receive P2P data requests sent to neighboring nodes; Step 43: Determine whether response data has been received from neighboring nodes within the backoff time. If yes, proceed to step 44; if no, proceed to step 45. Step 44: Send a NACK message and proceed to step 5; Step 45: No NACK message needs to be sent. Proceed to step 6.

[0010] Furthermore, the retreat time is 10-100ms; The specific calculation of the retreat time is as follows:

[0011] The base backoff time is 10ms.

[0012] Furthermore, step 6 also includes: The sender sends a heartbeat packet every 2 seconds. After receiving the heartbeat packet, the receiver replies with a status report, sends and receives the status report, and dynamically adjusts the parameters. The heartbeat packet includes the current session ID, sender status, latest multicast packet sequence number, and current recommended FEC redundancy.

[0013] Furthermore, the status report includes its own node ID, the maximum consecutive sequence number received, a list of missing sequence numbers, the average latency of the last 10 receptions, the FEC decoding success rate, and the current network load level.

[0014] Beneficial effects: This invention fundamentally suppresses "acknowledgment storms" and achieves efficient network load balancing. It completely abandons the traditional mechanism of receivers acknowledging (ACK) each data packet in reliable transmission, instead passively detecting packet loss through sequence number continuity detection, thus eliminating the risk of "acknowledgment storms" caused by a massive influx of acknowledgment messages to the sender. Through dynamic clustering and weighted election, the dispersed state feedback from a large number of receivers is aggregated into a unified report from a small number of representative nodes. This reduces the communication load on the control plane from O(N) level (related to the number of receivers) to O(K) level, greatly alleviating the processing pressure on the sender and the risk of congestion in the control network.

[0015] This invention constructs a multi-level defense system prioritizing local repair, significantly reducing transmission latency. Upon detecting packet loss, it first utilizes the redundant coding embedded in the data packets for local lossless recovery. For random, scattered, and small-scale packet loss, repair can be completed within milliseconds without any network interaction, achieving zero-latency compensation. When local FEC redundancy is insufficient, it does not immediately request assistance from the remote sender, but instead prioritizes requesting data from neighboring nodes with lower network latency. Edge caching and cooperation mechanisms shorten the retransmission path to the network edge, with latency far lower than retransmission from the sender, making it particularly suitable for applications with high real-time requirements.

[0016] This invention utilizes a heartbeat mechanism and status reports to continuously monitor the global network status (such as average latency, packet loss rate, and receiver load), and dynamically adjusts key parameters such as FEC redundancy, transmission rate, and NACK trigger threshold accordingly. This enables the system to adapt to different network conditions and service requirements, optimizing bandwidth utilization while ensuring reliability. Neighbor node collaboration and the representative node mechanism reduce the bottleneck risk of the sender acting as a single center. Even with high sender load or partial network failures, receivers can still effectively repair data through P2P, significantly enhancing the system's fault tolerance and robustness. A random backoff timer before retransmission requests effectively avoids channel contention caused by simultaneous requests from receivers during collective packet loss. The weighted election criteria for representative nodes (packet loss rate, bandwidth, stability) ensure that the best node in the network undertakes the coordination task, preventing "bad money drives out good" and improving overall system efficiency. The sender merges NACK requests with the same sequence number received within a fixed buffer period, requiring only one retransmission to satisfy the needs of multiple receivers, avoiding bandwidth waste caused by repeated retransmissions and significantly improving retransmission efficiency. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0018] Figure 1 This is a flowchart of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0020] The present invention will be further described below with reference to embodiments.

[0021] Example 1: Please refer to Figure 1 A method for ensuring the reliability of multicast transmission includes the following steps: Step 1: The sender assigns a globally unique and incrementing sequence number to each multicast data packet and adds FEC redundancy coding to the multicast data; Serial number: 32-bit session ID + 32-bit timestamp (milliseconds) + 32-bit incrementing sequence number; The session ID is randomly generated by the sender during the session; The timestamp is accurate to the moment it was sent; The sequence number is incremented starting from 0, and incremented by 1 for each multicast data packet sent. Step 2: The receiver receives multicast data packets, records consecutive sequence numbers through a sliding window, traverses the sequence numbers in the sliding window, and determines whether the sequence numbers are consecutive. If the determination is yes, no packet loss has occurred, and proceed to step 7; if the determination is no, proceed to step 3. The first in the sliding window Window size at time A dynamic adjustment strategy is adopted, with the maximum window size not exceeding 512 and the minimum not lower than 32; The calculation is as follows:

[0022]

[0023] This represents the average network latency over the past 10 seconds. This is the initial value for the window size of the sliding window; Step 3: The receiver identifies redundant packets in the received multicast data packets according to the FEC redundancy coding, counts the number of redundant packets, and determines whether the number of redundant packets is greater than or equal to the threshold. If it is, the receiver performs local error correction and data recovery, and then executes Step 7. If it is not, the receiver executes Step 4. Step 4: Start the random backoff timer, request response data from neighboring nodes, and determine whether response data from neighboring nodes is received within the backoff time. If yes, proceed to step 5; if no, proceed to step 6. Step 5: Send a NACK message to the sender. The sender collects NACK messages and counts the number of requests with the same sequence number within a fixed buffer period. When the count reaches the trigger value within the fixed buffer period, Step 6 is executed immediately. When the fixed buffer period expires, requests with the same sequence number are merged, and Step 6 is executed again. Step 6: Send a retransmission data command to the sender. Upon receiving the retransmission data command, the sender retransmits the multicast data packet to the receiver, updates the receive window, and then executes Step 7. Step 7: The application layer receives multicast data packets and processes them normally.

[0024] The K-means clustering algorithm is used to divide the receivers into subgroups. The subgroups are dynamically divided using "inter-node network latency" as the clustering index, and the size of each subgroup is controlled between 10 and 20 nodes.

[0025]

[0026] Number of subgroups; Representative node election: Each subgroup elects a representative node through a weighted voting method; For example, the node with the highest weight in the past minute is selected based on the packet loss rate (weight 0.4), bandwidth utilization (weight 0.3), and online time (weight 0.3). The election is held every 5 minutes.

[0027] The receivers are divided into subgroups, and each group selects a representative to provide feedback on the status, thereby reducing the overall communication volume.

[0028] Threshold: 15%.

[0029] Fixed cache period: 50ms.

[0030] Trigger value: 5 times.

[0031] 4. The specific steps are as follows: Step 41: Start the random backoff timer; Step 42: Receive P2P data requests sent to neighboring nodes; The specific operation of sending P2P data requests to neighboring nodes is as follows: in order of increasing latency. The unicast request messages are sent sequentially to the neighboring nodes. The request message includes the session ID and the missing sequence number; Step 43: Determine whether response data has been received from neighboring nodes within the backoff time. If yes, proceed to step 44; if no, proceed to step 45. This allows receiving nodes to retrieve lost data directly from neighboring nodes (rather than the central server), reducing the load on the central node.

[0032] Step 44: Send a NACK message and proceed to step 5; Step 45: No NACK message needs to be sent. Proceed to step 6.

[0033] The NACK message includes the target multicast address, session ID, list of missing sequence numbers, sending node ID, and estimated network latency.

[0034] The retreat time is 10-100ms; The specific calculation of the retreat time is as follows:

[0035] The base backoff time is 10ms.

[0036] Step 6 also includes: The sender sends a heartbeat packet every 2 seconds. After receiving the heartbeat packet, the receiver replies with a status report, sends and receives the status report, and dynamically adjusts the parameters. The heartbeat packet includes the current session ID, sender status (online / reloaded), latest multicast packet sequence number, and current recommended FEC redundancy. The status report includes its own node ID, the maximum consecutive sequence number received, the list of missing sequence numbers, the average latency of the last 10 receptions, the FEC decoding success rate, and the current network load level (light / medium / heavy).

[0037] The parameters for dynamic adjustment are as follows: 1. Transmission control parameters: Parameters that directly affect data transmission behavior.

[0038] 1. FEC redundancy: refers to the ratio of the number of redundant packets to the number of original packets in FEC encoding.

[0039] For example, adjust from (10, 8) (i.e., 25% redundancy) to (12, 8) (i.e., 50% redundancy).

[0040] 2. Sending rate / bitrate: Controls the amount of data sent per unit of time.

[0041] It decreases during congestion and increases during idle periods.

[0042] 3. Heart rate interval: When the heart rate is stable, it can be appropriately extended (e.g., from 2 seconds to 5 seconds), and maintained or shortened when the heart rate is unstable.

[0043] II. Protocol Behavior Parameters: Parameters that affect the interaction logic between the receiver and the sender.

[0044] 1. NACK trigger threshold: This is the "trigger value" mentioned in step 5. When network conditions are poor and packet loss is scattered, this threshold can be appropriately lowered (e.g., from 5 times to 3 times) to allow the sender to respond to retransmission requests more quickly. Conversely, it can be increased to reduce unnecessary retransmissions.

[0045] 2. Recommended sliding window size: The sender can suggest that the receiver adjust its initial window size in the heartbeat packet based on the average delay.

[0046] This approach fundamentally suppresses "acknowledgment storms" and achieves efficient network load balancing. It completely abandons the traditional mechanism of receivers acknowledging (ACK) every data packet in reliable transmission, instead passively detecting packet loss through sequence number continuity detection, thus eliminating the risk of "acknowledgment storms" caused by a massive influx of acknowledgment messages to the sender. Through dynamic clustering and weighted election, the dispersed state feedback from numerous receivers is aggregated into a unified report from a small number of representative nodes. This reduces the communication load on the control plane from O(N) level (related to the number of receivers) to O(K) level, significantly alleviating the processing pressure on the sender and the risk of congestion in the control network.

[0047] A multi-level defense system prioritizing local repair was constructed, significantly reducing transmission latency. Upon detecting packet loss, local lossless recovery is first performed using redundant coding embedded in the data packets. For random, scattered, and small-scale packet loss, repair can be completed within milliseconds without any network interaction, achieving zero-latency compensation. When local FEC redundancy is insufficient, it does not immediately request assistance from the remote sender but prioritizes requesting data from neighboring nodes with lower network latency. Edge caching and collaboration mechanisms shorten the retransmission path to the network edge, with latency far lower than retransmission from the sender, making it particularly suitable for applications with high real-time requirements.

[0048] The sender continuously monitors the global network status (such as average latency, packet loss rate, and receiver load) through a heartbeat mechanism and status reports, and dynamically adjusts key parameters such as FEC redundancy, transmission rate, and NACK trigger threshold accordingly. This enables the system to adapt to different network conditions and service requirements, optimizing bandwidth utilization while ensuring reliability. Neighbor node collaboration and the representative node mechanism reduce the bottleneck risk of the sender acting as a single center. Even with high sender load or partial network failures, receivers can still effectively repair data through P2P, significantly enhancing the system's fault tolerance and robustness. A random backoff timer before retransmission requests effectively avoids channel contention caused by simultaneous requests from receivers during collective packet loss. The weighted election criteria for representative nodes (packet loss rate, bandwidth, stability) ensure that the best node in the network undertakes coordination tasks, preventing "bad money drives out good" and improving overall system efficiency. The sender merges NACK requests with the same sequence number received within a fixed buffer period, requiring only one retransmission to satisfy the needs of multiple receivers, avoiding bandwidth waste caused by repeated retransmissions and significantly improving retransmission efficiency.

[0049] NACK: Negative confirmation.

[0050] P2P: Peer-to-Peer.

[0051] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for ensuring the reliability of multicast transmission, characterized in that: Includes the following steps: Step 1: The sender assigns a globally unique and incrementing sequence number to each multicast data packet and adds FEC redundancy coding to the multicast data; Step 2: The receiver receives multicast data packets, records consecutive sequence numbers through a sliding window, traverses the sequence numbers in the sliding window, and determines whether the sequence numbers are consecutive. If the determination is yes, no packet loss has occurred, and proceed to step 7; if the determination is no, proceed to step 3. Step 3: The receiver identifies redundant packets in the received multicast data packets according to the FEC redundancy coding, counts the number of redundant packets, and determines whether the number of redundant packets is greater than or equal to the threshold. If it is, the receiver performs local error correction and data recovery, and then executes Step 7. If it is not, the receiver executes Step 4. Step 4: Start the random backoff timer, request response data from neighboring nodes, and determine whether response data from neighboring nodes is received within the backoff time. If yes, proceed to step 5; if no, proceed to step 6. Step 5: Send a NACK message to the sender. The sender collects NACK messages and counts the number of requests with the same sequence number within a fixed buffer period. When the count reaches the trigger value within the fixed buffer period, Step 6 is executed immediately. When the fixed buffer period expires, requests with the same sequence number are merged, and Step 6 is executed again. Step 6: Send a retransmission data command to the sender. Upon receiving the retransmission data command, the sender retransmits the multicast data packet to the receiver, updates the receive window, and then executes Step 7. Step 7: The application layer receives multicast data packets and processes them normally.

2. The method for ensuring multicast transmission reliability according to claim 1, characterized in that, Threshold: 15%.

3. The method for ensuring multicast transmission reliability according to claim 2, characterized in that, Fixed cache period: 50ms.

4. The method for ensuring multicast transmission reliability according to claim 3, characterized in that, Trigger value: 5 times.

5. The method for ensuring multicast transmission reliability according to claim 4, characterized in that, 4. The specific steps are as follows: Step 41: Start the random backoff timer; Step 42: Receive P2P data requests sent to neighboring nodes; Step 43: Determine whether response data has been received from neighboring nodes within the backoff time. If yes, proceed to step 44; if no, proceed to step 45. Step 44: Send a NACK message and proceed to step 5; Step 45: No NACK message needs to be sent. Proceed to step 6.

6. The method for ensuring multicast transmission reliability according to claim 5, characterized in that, The retreat time is 10-100ms; The specific calculation of the retreat time is as follows: The base backoff time is 10ms.

7. The method for ensuring multicast transmission reliability according to claim 6, characterized in that, Step 6 also includes: The sender sends a heartbeat packet every 2 seconds. After receiving the heartbeat packet, the receiver replies with a status report, sends and receives the status report, and dynamically adjusts the parameters. The heartbeat packet includes the current session ID, sender status, latest multicast packet sequence number, and current recommended FEC redundancy.

8. The method for ensuring multicast transmission reliability according to claim 7, characterized in that, The status report includes its own node ID, the maximum consecutive sequence number received, the list of missing sequence numbers, the average latency of the last 10 receptions, the FEC decoding success rate, and the current network load level.

Images