Method for realizing reliable multicast under Linux platform

Abstract

According to the implementation method for reliable multicast under the Linux platform, the problems of poor reliability, high packet loss rate, data transmission disorder and the like in the prior art are solved by adopting data packet numbering, a confirmation mechanism, a retransmission mechanism and an out-of-order processing method, and the reliability of the reliable multicast under the Linux platform is improved through a dynamic bandwidth control technology. When the method provided by the invention is adopted, the transmission rate can be adaptively adjusted in different network environments, and the stability and efficiency of multicast are improved. In addition, the implementation method provided by the invention has relatively high portability on a Linux platform, and can be widely applied to various network application scenes.

Description

Technical Field

[0001] The present invention relates to the technical field of computer networks, and particularly to a method for implementing reliable multicast under the Linux platform. Background Art

[0002] With the continuous development of the securities and financial industries and the continuous growth of the securities investor group, the distribution of market data through multicast technology has become a mainstream. Multicast communication mainly involves the third layer (network layer) and the fourth layer (transport layer) of the OSI model. The network layer is responsible for the addressing and routing of multicast data, and the transport layer is responsible for the transmission of multicast data. Currently, UDP is the most commonly used transport protocol in multicast communication. Since the data transmission of UDP itself has three characteristics: packet loss, out-of-order, and duplication, the multicast communication using the UDP protocol also inherits these three characteristics. However, the securities market has high requirements for data consistency and real-time performance and cannot tolerate data loss. Therefore, an attempt is made to increase reliability by adopting Pragmatic General Multicast (PGM) on the basis of UDP, but the effect is not ideal.

[0003] The main reasons for UDP packet loss are as follows:

[0004] 1) The network device itself is busy with communication;

[0005] 2) The multicast sending speed is too fast and the sending buffer is full;

[0006] 3) The multicast receiver receives data too slowly, resulting in overflow and overwrite;

[0007] 4) There are system instructions such as fork in the multicast receiving program that are prone to causing thread freezing.

[0008] The packet loss rate can be reduced by the following methods:

[0009] 1) The network layer can perform multicast pruning to reduce the scope of multicast data, configure QOS, and set DSCP to AF41 in the multicast data packet to improve the packet arrival rate;

[0010] 2) Introduce a flow control mechanism at the multicast sending end. With the help of the event notification model of EPoll, when there is idle space in the sending buffer, construct multicast packets of a specific size reasonably according to the size of the idle area and deliver them to ensure that the multicast packets can be correctly delivered to the physical network;

[0011] 3) The receiver uses an independent real-time level thread and uses a combination of EPoll events and active reception to read the arriving multicast packets as soon as possible and transfer them to its own data queue for subsequent processing;

[0012] 4) Optimize system parameters to increase the size of the network buffer and the queue length.

[0013] The biggest problem in UDP-based multicast communication is that it can only reduce the packet loss rate but cannot avoid packet loss. In an actual network environment, link aggregation technology is usually used, which will further amplify the problems of packet out-of-order and packet duplication. Under Linux, there is an open-source implementation of PGM called OpenPGM, which uses the NACK (Negative Acknowledgment) method for confirmation. Negative Acknowledgment means that only the receiver requests retransmission after detecting packet loss, which is suitable for environments with a large number of receivers.

[0014] However, data retransmission still uses the UDP protocol. Considering that in an actual production environment, the network is very busy, which may lead to a large number of packet losses within a certain period of time. If packet retransmission still uses the same UDP protocol implementation, it may face the situation of continuous packet loss, which will further lead to a large amount of data delay, seriously affecting the real-time performance and consistency of securities market data. Moreover, combined with the large amount of data initialization operations brought about after the downstream data server restarts, it will further affect the reliability of UDP transmission.

[0015] There are also issues of disaster recovery and automatic migration that need to be considered for the upstream server. Therefore, how to implement a reliable and efficient multicast transmission method on the Linux platform is an issue to be solved in the current field of securities market data synchronization. Summary of the Invention

[0016] The technical problem to be solved by the technical solution of the present invention is: how to implement a reliable and efficient multicast transmission method on the Linux platform.

[0017] The technical solution of the present invention provides a method for implementing reliable multicast under the Linux platform, including the following steps:

[0018] The upstream data server obtains the market change data of the upper service layer, uses the control function to send the corresponding multicast definition information and establish the corresponding multicast group to the downstream data server, and the upper service layer splits the market change data into a first preset number of equally sized shard packets and numbers them in sequence to obtain a first numbered group and the corresponding shard packets. Then, the Cauchy-Reed-Solomon algorithm is used to continue numbering after the first numbered group and generate the corresponding shard packets, obtaining the multicast data with packet numbers and caching it;

[0019] When the number of lost packets in the multicast data with packet numbers is less than or equal to the number of continued numbering after the first numbered group, it is determined that there is a certain small range of packet loss. At this time, only out-of-order restoration is required;

[0020] When the continuous loss quantity in the multicast data with packet numbers is greater than the quantity of continuous numbering after the first numbered group, resulting in the inability to restore data according to the packet numbers in combination with the erasure code algorithm, it is marked as a lost packet, and the TCP protocol is used to obtain the cached multicast data with packet numbers for asynchronous packet replenishment and out-of-order restoration;

[0021] When it is determined to perform asynchronous packet replenishment, but due to the physical network being in a network interruption and / or extremely congested situation, resulting in the communication timeout of asynchronous packet replenishment using the TCP protocol, it is determined that the data marked as lost packets is permanently lost, and the downstream data server obtains the differential data between the market change data and the market data snapshot point of the upstream data server for snapshot data initialization synchronization;

[0022] During out-of-order restoration, the complete data object corresponding to a packet number is pushed into the FIFO queue, and the sorting thread pops data from this queue and places it into an ordered list map sorted in ascending order of packet numbers, including the key as the packet number and the value as the corresponding data object, and checks the packet number of the top object to simulate the sequential arrival of multicast data in the TCP protocol;

[0023] The downstream data server connects to the upstream data server, joins the corresponding multicast group according to the multicast definition information, receives the multicast data with packet numbers, and restores the data according to the packet numbers in combination with the erasure code algorithm.

[0024] Preferably, when the snapshot data initialization synchronization fails, it is switched to the upstream data server to re-initialize the data.

[0025] Preferably, the process of re-initializing the data supports the physical separation of the multicast channel and the data initialization channel.

[0026] Preferably, the implementation method further includes selecting a preset network segment to support multicast during network environment setting, and enabling multicast pruning on the switch of the preset network segment to reduce unnecessary transmission paths, reduce bandwidth consumption, and improve efficiency.

[0027] Preferably, the upstream data server is provided with a first TCP port listening for the multicast management channel and a second TCP port listening for the market data snapshot initialization channel.

[0028] Preferably, the upstream data server adds the change data of the upper-layer market data to a variable-size buffer object, and obtains the data to be multicast according to the change data.

[0029] Preferably, the data restoration according to the packet numbers in combination with the erasure code algorithm is performed using an independent thread.

[0030] The technical solution of the present invention proposes a method for implementing reliable multicast under the Linux platform. By adopting packet numbering, confirmation mechanism, retransmission mechanism and out-of-order processing method, it solves the problems of poor reliability, high packet loss rate and out-of-order data transmission in the prior art. Through dynamic bandwidth control technology, when the method provided by the present invention is adopted, the transmission rate can be adaptively adjusted in different network environments, improving the stability and efficiency of multicast. In addition, the implementation method of the technical solution of the present invention has high portability on the Linux platform and can be widely applied to various network application scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 It is a schematic diagram for splitting using the Cauchy - Reed - Solomon algorithm;

[0032] Figure 2 It is a schematic diagram of the compilation rule for the packet numbers of the split packets;

[0033] Figure 3 It is a flowchart of a method for implementing reliable multicast under the Linux platform. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0034] The present invention will be further described below in conjunction with specific embodiments. It should be understood that these embodiments are only used to illustrate the present invention and not to limit the scope of the present invention. In addition, it should be understood that after reading the content taught by the present invention, those skilled in the art can make various changes or modifications to the present invention, and these equivalent forms also fall within the scope defined by the appended claims of this application.

[0035] In order to overcome the UDP multicast problems in the prior art and solve the reliable multicast of securities market data in a busy or unstable network, the embodiments of the present invention provide a method for multicast data in a high packet loss rate environment, and at the same time provide a fault tolerance processing mechanism for the securities market data source. The method for reliable multicast in a high packet loss rate environment includes:

[0036] 1) The upstream data server (multicast data sender) is also responsible for the control function and sends information such as multicast definitions to the downstream server (multicast data receiver);

[0037] 2) The downstream service connects to the upstream service, joins the corresponding multicast group according to the issued control definition, receives the multicast data, and restores the data according to the packet number combined with the erasure code algorithm, supporting the restoration of a certain small range of packet loss and out-of-order;

[0038] 3) Mark the packets that cannot be correctly restored as lost packets and use the TCP protocol for asynchronous packet supplementation;

[0039] 4) There is an out-of-order situation between the data packet numbers received by multicast and those obtained by the asynchronous packet retransmission task. After caching the received data, it is rearranged and simulated as a TCP time-sequential data stream and delivered to the upper-layer service.

[0040] 5) Considering the situation of network interruption, some data will be missing in the simulated TCP data stream. Provide a mechanism for the upper layer to actively pull the missing service layer data, and finally achieve the consistency of upper-layer service data synchronization.

[0041] 6) Considering that the initialization process of service layer data causes a large amount of bandwidth occupation, support the physical separation of the multicast channel and the data initialization channel.

[0042] 7) Considering the fault tolerance of the entire system, the upstream server can use the Master-Slave mode to provide automatic fault switching.

[0043] The multicast packet loss situations of securities market data are classified into the following categories, and different solutions are adopted.

[0044] 1) For a small range of out-of-order and extremely small amount of packet loss, no packet retransmission is required. Here, it is defined that the loss quantity < = 3 (the quantity numbered after the first numbered group) in 16 consecutive multicast packets (multicast data with data packet numbers).

[0045] 2) There is a situation of continuous packet loss.

[0046] 3) After determining the packet loss, the packet retransmission task cannot be completed within the specified time.

[0047] For the first type of problem of small-range out-of-order and occasional packet loss of data, we use the Cauchy-Reed–Solomon Algorithm to solve it, as Figure 1 shown.

[0048] The size of each shard packet is the same. According to the requirements of the algorithm, it must be a multiple of 8, with a minimum of 16 and a maximum of 512. In the current solution, we use 176, and the shard length is 8 * 176 = 1408, which is suitable for placing in an MTU.

[0049] This algorithm is an efficient encoding and decoding method, which uses Erasure Codes to solve data recombination. Each data packet for multicast adopts a fixed-length structure. The upper-layer service splits the data to be multicast according to this fixed length, and the data packet numbers of the split packets are compiled according to the rules as Figure 2 shown.

[0050] The 13 shards after splitting the original data use the same PkgNo number. These 13 shard numbers, i.e., 0 to 12, are filled in the ShardID position. Three parity shard packets (13 to 15) are calculated using the Cauchy-Reed–Solomon algorithm. In this way, the upper-layer service packet is split into fixed-length 13 + 3 data packets for multicast. After receiving the multicast downstream, the packets are grouped and cached according to PkgNo. When the number of received shard packets >= 13, restoration is performed. This can support the out-of-order arrival of 13 + 3 shard packets and tolerate the loss of a maximum of 3 shards.

[0051] Packet loss determination method: When shards with different subsequent PkgNOs arrive and the number of shard packets with the same previous PkgNo is less than 13, the data packets corresponding to the previous PkgNO are marked as completely lost, and an asynchronous packet replenishment task for that PkgNo is started. Considering the possible large out-of-order situation of data shards (shard out-of-order spanning different PkgNo ranges), data with n PkgNo numbers can be cached simultaneously. When the difference between the PkgNO of the received data packet and the smallest PkgNO in the cache is greater than n, it means that the data packet corresponding to the smallest PkgNO in the cache is completely lost. Then, the data packet corresponding to that PkgNO is removed from the cache and marked as lost, and an asynchronous packet replenishment task for the packet corresponding to that PkgNo is enabled.

[0052] In the second case, when packets that cannot be restored by the Cauchy-Solomon algorithm due to consecutive shard losses occur, the TCP-based packet replenishment channel is used to actively pull the data packets with the corresponding PkgNO from the upstream. The upstream caches a specific number of data packets within a recent period of time, and this cache is updated in a rolling manner.

[0053] In the third case, when the physical network is extremely congested and the TCP packet replenishment communication times out, it means that the corresponding data packet is permanently lost. The multicast downstream service will start the re-initialization process and realign with the upstream data snapshot point. If the alignment task cannot be completed, the upstream server is switched, such as switching from the master node to the slave node to completely re-initialize the data synchronization.

[0054] Considering the case of asynchronous packet retransmission after packet loss, the PkgNo in the market data packets finally received by the multicast downstream may be out of order. Therefore, a sorting algorithm needs to be introduced in the multicast downstream to correct the problem of out-of-order PkgNo. This solution uses a FIFO queue and a sorting thread to simulate the sequential arrival of TCP data. The multicast receiving thread and the packet retransmission thread push the complete data object corresponding to a PkgNO into the FIFO queue. The sorting thread pops data from this queue and puts it into an object of std::map<std::uint64,void*>. The key of this map is PkgNo, and the value is the corresponding data object. Since the map is an ordered list and sorts PkgNo from small to large, each time the sorting thread pops data and puts it into this map, it is necessary to check the PkgNo of the top object. If the difference between the PkgNO of the top object and the PkgNO of the data object popped to the upper service layer last time is 1, it means that the top data object is consecutive. After popping this data object, update the PkgNo of the latest data, and check and process the subsequent top objects according to this rule until the difference is greater than 1 or the map is empty, indicating that it is necessary to wait for a new multicast packet to arrive. Through this method, the consistency between the order of processing data packets by the upper service layer downstream and the order of sending multicast packets is ensured.

[0055] A flowchart of an implementation method of reliable multicast under the Linux platform is as Figure 3 shown.

[0056] The embodiments of the present invention will be further described below with reference to the above drawings.

[0057] This solution is currently used in the multicast distribution scenario of securities market data, but is not limited to the specific usage scenarios described. Scenarios with continuous distribution of a large amount of data, requiring data initialization alignment, and pursuing high availability, data consistency, and low-latency synchronization are all suitable for this solution.

[0058] In the current implementation solution, the upstream multicast service and the downstream multicast receiving service are limited to the Linux operating system. The steps to enable and run are as follows:

[0059] 1) First is the network environment setting. To prevent the scope of multicast data transmission from expanding, a network segment is selected to support multicast. Suppose the network segment selected here is 10.10.108.0 / 21. Multicast pruning is enabled on the switch of this network segment to reduce unnecessary transmission paths, reduce bandwidth consumption, and improve efficiency.

[0060] 2) All upstream and downstream servers adjust the kernel parameters to increase the size of the UDP read and write buffers, and try to reduce the situation where the UDP receive buffer is overwritten due to the inconsistency between the data processing layer speed and the multicast packet arrival rate.

[0061] 3) The upstream multicast service program starts, listening on two TCP ports, which are used for the multicast management channel and the market data snapshot initialization channel respectively. Considering that the snapshot data file is large, usually larger than 10GB, a dual network card is used in the entire network environment to prevent the snapshot data synchronization from occupying the multicast bandwidth and exacerbating the multicast packet loss phenomenon (a single network card needs to use TC to limit the network speed of the snapshot synchronization channel port). Assume that the multicast channel uses network card eth0 and the snapshot data initialization channel uses network card eth1. According to the configuration, the multicast uses a private multicast IP address in the range of 239.0.0.0 / 24 as the multicast group. Here, assume that the multicast address 239.0.0.1 is used. Select eth0 to enable the multicast function of 239.0.0.1. After the multicast is enabled, start listening on two TCPs.

[0062] 4) The upstream multicast service will continuously obtain the data to be multicast according to the upper-layer market data change events. Considering that the size of the changed data is irregular, the market change data is first uniformly added to the variable-size buffer object.

[0063] 5) The multicast service monitors the writable state of the Socket used for multicast communication. When there is enough free space in the write buffer, read a specific size of content from the data buffer object. If it is insufficient, fill it with zeros. Divide the read data into 13 shards, calculate another 3 parity shards using the Cauchy-Reed–Solomon algorithm, and send them through the multicast address 239.0.0.1 without considering whether there is a corresponding multicast client instance. Since the multicast pruning is adopted in the network segment 10.10.108.0 / 21, no actual multicast data transmission will occur in the case of no multicast client instance.

[0064] 6) Start the downstream multicast client. This client uses a TCP connection to the multicast management channel of the upstream service to download the current multicast definition, including the erasure code algorithm parameters used, the multicast address 239.0.0.1, and the IP address and port information of the data initialization channel. Select the corresponding local network card to join the multicast group 239.0.0.1 according to the access address of the multicast channel.

[0065] 7) The multicast client uses a single-threaded Epoll-based event notification to read the multicast shard packets from the multicast group, and immediately add the read shard packets to the corresponding FIFO queue, so as to minimize the blocking of the data reception task.

[0066] 8) Use an independent thread to reconstruct the sharded packets, constructing an array with n slots. Each slot has a fixed 13 + 3 positions for storing the multicast shards corresponding to the shard IDs. Each slot corresponds to a PkgNo. Each time, extract a multicast shard packet from the FIFO queue and place it into the corresponding slot. At the same time, detect whether the number of shards in the slot reaches 13. Once it reaches 13, perform reconstruction. If the 13 shard numbers are 0 to 12, directly splice the 13 shards in order to restore the original data packet. Otherwise, use the Cauchy-Reed–Solomon algorithm to restore the original data packet based on the parity shards. The successfully restored original data packet is put into another FIFO queue for TCP flow simulation, waiting for other threads to simulate the TCP data stream reception action. At the same time, empty the corresponding slot for data packets of other PkgNos to use.

[0067] 9) Packet loss judgment and processing need to consider the cases of large-area continuous packet loss or out-of-order delay. In both cases, it is manifested that the difference between the PkgNo of the assembled complete data packet and the PkgNo of the previous complete data packet is greater than 1. The missing PkgNos in the middle may be packet loss or may arrive with delay. To improve the real-time performance of data synchronization, it is assumed that actual packet loss has occurred in both cases. For the data numbers between two PkgNos, directly start the corresponding asynchronous packet retransmission task. If there are types of packets that arrive with delay among these PkgNos, they will be added to the FIFO queue for TCP flow simulation according to the processing method in step 8 above. The data retransmitted asynchronously will also be added to the FIFO queue for TCP flow simulation. The TCP flow simulation processing thread is responsible for eliminating duplicate data, similar to the duplicate packet processing algorithm in TCP communication.

[0068] 10) The asynchronous packet loss task communicates using the multicast management channel to notify the upstream server to retransmit the data packets corresponding to the given range of numbers. This is achieved by leveraging the reliability of the TCP protocol. The upstream server extracts the corresponding data packets from the multicast packet cache according to the PkgNO and sends them to the downstream. Considering the memory usage, there is a certain limit on the number of multicast packets cached upstream. Use 3 cache groups to represent the current, earlier, and about-to-be-lost situations respectively. Here, use 1W as the group boundary. The currently multicast data is appended to the current group. Once it reaches the 1W boundary, roll the current group into the earlier situation, and the previous earlier group is incorporated into the about-to-be-lost situation, which is recycled by the GC module. The downstream packet retransmission situation can quickly extract the corresponding data and return it according to the PkgNo range.

[0069] 11) If the PkgNo required for downstream packet replenishment has been recycled in the upstream cache, it means that the time point positions of the downstream data and the upstream data deviate too much. By actively disconnecting the TCP management channel of this downstream upstream, the downstream is triggered to re-initialize and align the data, which can quickly eliminate the data differences between the upstream and downstream. Similarly, if the downstream times out for TCP packet replenishment (usually the timeout is set to 10 seconds), it generally indicates that the current network communication is too busy or there are problems. The connection is actively disconnected and re-initialized and aligned. If the initialization cannot be completed during this process, it is suspected that the corresponding upstream server has failed. The downstream automatically switches to the upstream server in slave mode to re-initialize to avoid the upstream failure node. In this case, the downstream instance will try to switch back to the Master node during the idle phase at night to restore the original deployment structure.

[0070] 12) The TCP time-series data stream uses an independent thread to simulate TCP data reception. Since the upper-layer service data protocol will be parsed in this thread and some service functions will also be processed, there may be certain blocking situations. To prevent affecting the reception and processing of the underlying UDP multicast sharding, an independent thread is used, and a buffer is established using a FIFO queue in the middle. The time series of the data stream is determined by the PkgNO of the packet. This PkgNo is an incrementing number. The data packets delivered by the multicast data reception layer to the FIFO queue of the current TCP simulation stream may be repeated (duplicate packets caused by asynchronous packet replenishment), and there is also a certain degree of out-of-order situation. Therefore, when initializing and starting, the PkgNO of the first data packet is used as the initial comparison benchmark. For subsequent data packets extracted from the FIFO, if the PkgNo is greater than or equal to this comparison benchmark value, it means they are duplicate packets and are directly discarded. Each time a new incoming data packet is sorted and popped for upper-layer processing, this comparison benchmark is updated. The following method is used to organize the out-of-order data in the FIFO:

[0071] Use an object in the format of std::map<PkgNo, PkgData>. Relying on the ordered feature of PkgNo, each Pkg extracted from the FIFO is placed into this map. Read whether the difference between the Key of the first element and the comparison benchmark is 1. If so, it means the first object in the Map table is the next data object. Pop the data object and call the service layer data stream parsing function to perform protocol parsing. If it is found that the service data is discontinuous during protocol layer parsing, a service data packet replenishment is initiated at the service layer. This discontinuity of service data is manifested as the absence of data stream in TCP communication. The retransmission mechanism of TCP packet loss is simulated through service layer packet replenishment.

[0072] 13) The data sent to the service layer through the TCP timing data stream maintains the timing of the upstream multicast server's data transmission. However, in this solution, the multicast data is designed to be continuously multicast, the service data is constantly rolling and changing, and downstream servers are allowed to have problems for maintenance or failure restart. Therefore, when the downstream restarts or switches to the upstream multicast data source, the market business data snapshot points need to be initialized and synchronized. The amount of synchronized data is huge and requires a certain amount of time. There is a certain time difference between the snapshot data checkpoint, such as being inconsistent with the time point of the multicast data. Therefore, an alignment action is required. The alignment scheme is to temporarily store the received multicast data. After the snapshot data synchronization is completed, according to the difference between the record ID of the snapshot data and the first multicast data record ID, the initialization data synchronization channel is used again to extract, merge, and align. After the alignment is completed, the temporarily stored multicast data is merged into the initialized data. The subsequent received multicast data is directly merged to achieve the consistency between the downstream data and the upstream data.

[0073] The beneficial effects of the embodiments of the present invention are as follows:

[0074] The embodiments of the present invention solve the problems of poor reliability, high packet loss rate, and out-of-order data transmission in the prior art by adopting the packet numbering, confirmation mechanism, retransmission mechanism, and out-of-order processing method. Through the dynamic bandwidth control technology, the embodiments of the present invention can adaptively adjust the transmission rate in different network environments, improving the stability and efficiency of multicast. In addition, the implementation method of the embodiments of the present invention has high portability on the Linux platform and can be widely applied to various network application scenarios.

Claims

1. A method for implementing reliable multicast under Linux platform, characterized in that: The following steps are involved: The upstream data server obtains the market change data of the upper business layer, uses the control function to send the multicast definition information corresponding to the market change data to the downstream data server and establishes the corresponding multicast group, and the upper business layer splits the market change data into a first preset number of fragment packets of the same size and sequentially numbers them to obtain a first number group and corresponding fragment packets, uses the Cauchy-Reed-Solomon algorithm to continue numbering after the first number group and generate corresponding fragment packets, obtains multicast data with data packet numbers and caches them; When the number of lost multicast data with data packet numbers is less than or equal to the number of packets that continue to be numbered after the first numbering group, it is determined that there is a certain small range of packet loss, and only out-of-order restoration is required at this time; When the number of consecutive losses in the multicast data with data packet numbers is greater than the number of data packets that continue to be numbered after the first numbering group, making it impossible to restore the data based on the data packet numbers combined with the erasure code algorithm, it is marked as a packet loss, and the TCP protocol is used to obtain the cached multicast data with data packet numbers for asynchronous packet replenishment and out-of-order restoration; When it is determined to perform asynchronous packet replenishment, but the physical network is disconnected and / or extremely congested, causing the TCP protocol to time out, the data marked as packet loss is determined to be lost forever, and the downstream data server obtains the difference data between the market change data and the market data snapshot point of the upstream data server to perform snapshot data initialization synchronization; When restoring out of order, a complete data object corresponding to a packet number is pushed to the FIFO queue. The sorting thread pops the data from the queue and puts it into an ordered list map, which includes the key as the packet number and the value as the corresponding data object, sorted from small to large according to the packet number. The packet number of the top object is checked to simulate the timed arrival of multicast data in the TCP protocol. The downstream data server is connected to the upstream data server, joins the corresponding multicast group according to the multicast definition information, receives the multicast data with the data packet number, and restores the data according to the data packet number combined with the erasure code algorithm.

2. The method for implementing reliable multicast under Linux platform as claimed in claim 1, characterized in that: When the snapshot data initialization synchronization fails, the upstream data server is switched to reinitialize the data.

3. The method for implementing reliable multicast under Linux platform as claimed in claim 2, characterized in that: The process of reinitializing data supports physical separation of the multicast channel and the data initialization channel.

4. The method for implementing reliable multicast under Linux platform as claimed in claim 1, characterized in that: The implementation method also includes selecting a preset network segment to support multicast when setting up the network environment, and enabling multicast pruning on the switch of the preset network segment to reduce unnecessary transmission paths, reduce bandwidth consumption and improve efficiency.

5. The method for implementing reliable multicast under Linux platform as claimed in claim 1, characterized in that: The upstream data server is provided with a first TCP port listening for a multicast management channel and a second TCP port listening for a market data snapshot initialization channel.

6. The method for implementing reliable multicast under Linux platform as claimed in claim 1, characterized in that: The upstream data server adds the change data of the upper-layer market data to the size-variable buffer object, and obtains the data to be multicast according to the change data.

7. The method for implementing reliable multicast under Linux platform as claimed in claim 1, characterized in that: The data restoration is performed using an independent thread in combination with an erasure code algorithm according to the data packet number.

Images