A data collaboration method based on QUIC protocol in multi-satellite weak network scenario

Abstract

The present invention discloses a data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol; including: a QUIC-based HTTP service for file metadata management and transmission task management; a QUIC-based Socket component that provides message two-way communication and file transfer functions; and a data collaboration service for realizing file synchronization, data migration, and message communication. The present invention realizes efficient file synchronization, breakpoint resume, and secure integrity verification through key technologies such as file differential management, task management, and message communication modules, thereby ensuring effective and stable data interaction capabilities between satellite nodes. The present invention is suitable for application scenarios such as message communication, file synchronization, and breakpoint resume in space-based networks, and aims to improve the rate, reliability, and security of data transmission.

Description

Technical Field

[0001] The present invention relates to the field of network communication technology, and in particular to a data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol. Background Art

[0002] The multi-satellite weak network scenario refers to a constellation system composed of multiple satellites, in which the communication link is affected by factors such as the Earth's atmosphere, solar activity, and satellite position changes, and the network conditions are extremely unstable. The traditional TCP protocol performs poorly under these conditions. The QUIC (Quick UDP Internet Connections) protocol, as a new transport layer protocol based on UDP, has the advantages of fast connection establishment, low latency, multiplexing, and high security. It is very suitable for multi-satellite weak network communication scenarios. Therefore, realizing a stable and reliable data collaboration system based on the QUIC protocol has become a crucial issue for multi-satellite mission collaboration in the constellation.

[0003] The present invention proposes and implements a data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol. The satellite network performs large-scale data processing and storage, and its communication link is affected by factors such as solar activity and satellite position changes, and the network conditions are extremely unstable. The traditional TCP protocol performs poorly under these conditions and will have connection jitter problems. The QUIC protocol, as a new protocol implemented based on UDP, has the advantages of fast connection establishment, low latency, multiplexing, and high security, and is very suitable for satellite network communications. Therefore, the present invention designs and implements a message communication and data synchronization mechanism for a multi-satellite weak network environment based on the QUIC protocol. Summary of the invention

[0004] The purpose of the present invention is to provide a data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol, to provide simple and fast protocol encoding and decoding, point-to-point file transfer capabilities, reliable breakpoint resumption processing and secure integrity verification capabilities between satellite nodes, and to ensure that the satellite nodes of the constellation system have effective message communication and data interaction capabilities in a weak network environment.

[0005] To achieve the above purpose, the technical solution adopted by the present invention is as follows:

[0006] The present invention provides a data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol, comprising the following steps:

[0007] Step 1: Start a QUIC service for file sending and an http3 service based on the QUIC protocol on each satellite node;

[0008] Step 2: The satellite node requests the file metadata of the target directory from the neighboring satellite node, performs a differential comparison between the obtained file metadata and the mirror file of the local directory, and selects the list of files to be updated in the local directory and the computing nodes where they are located;

[0009] Step 3: Submit the selected target file information to the task queue, and start the file transfer task monitoring heartbeat;

[0010] Step 4: Create a QUIC client for file reception, establish a connection with the QUIC server on the satellite node where the target file is located, and send the task information of file transfer;

[0011] Step 5: The QUIC client of the current node and the QUIC server of the target satellite node start to transfer file data; during the file data transmission process, the network between satellite nodes fluctuates; if the connection is not disconnected, the retry mechanism is triggered based on the QUIC protocol, and the data is tried to be resent; if the connection is disconnected, the breakpoint resume mechanism is triggered;

[0012] Step 6: After the file transfer is completed, compare it with the received CRC check code; if the comparison is consistent, overwrite the original file and synchronize the file metadata; if the comparison is inconsistent, send a transmission failure message and wait for retransmission.

[0013] Furthermore, the step 1 includes the following sub-steps:

[0014] (1.1) Create a QUIC server and register the first reader and the first writer for the server; the first writer encodes the incoming message type of any type into the agreed protocol format, adds the magic number, version number, packet type, and packet length as the protocol header; the first reader reads data of the specified packet length from the QUIC stream and decodes it into a message object;

[0015] (1.2) Register a first data stream handler and a message handler for file sending with the QUIC service.

[0016] Furthermore, in step 2, the satellite node periodically obtains file information of neighboring nodes through a heartbeat mechanism.

[0017] Furthermore, in step 2, the obtained file metadata is differentially compared with the mirror file of the local directory, the latest modified metadata information of each file is filtered out, and the node where the file is located is found; if it is a local node, it means that the latest version of this file is local and does not need to be synchronized from other nodes; if it is a non-local node, it is determined whether it is already in the transmission task queue, and if not, it is added to the transmission task queue.

[0018] Furthermore, the step 3 includes the following sub-steps:

[0019] (3.1) Take out the file task list to be synchronized from the task queue, use the snowflake algorithm to generate a unique task ID for each task, and send it to the node where the target file is located;

[0020] (3.2) After receiving the file transfer task, the target node submits it to the sending queue and saves the new transfer task to the local database;

[0021] (3.3) The file transfer task monitoring thread sends heartbeats to the target node at regular intervals to obtain the file transfer tasks to be executed; after obtaining the tasks, the file receiving client is started.

[0022] Furthermore, the step 4 includes the following sub-steps:

[0023] (4.1) Create a QUIC client and register a second reader and a second writer for the client;

[0024] (4.2) Register a second data stream handler for file reception with the QUIC client;

[0025] (4.3) The QUIC client initiates a connection request to the server. After the connection is established, the data stream processors of the server and the client begin to execute asynchronously, waiting for message communication and file transfer;

[0026] (4.4) The QUIC client sends information about the file transfer task to the server through the second writer, including the unique ID of the transfer task, the task type, the sender node IP, the receiver node IP, the task status, the absolute path of the file, the receiver storage location, whether the file needs to be compressed, the file offset, and the total size of the file; the client changes the task status to the ready state before sending the task information.

[0027] Furthermore, the step 5 includes the following sub-steps:

[0028] (5.1) After the QUIC server reads the file transfer task sent by the client through the first reader, it finds the target file. If the file does not exist, it sends a failure response to the QUIC client and closes the connection;

[0029] (5.2) The server determines whether the task status is ready. If not, it waits for the next message from the client. If it is ready, it enters the file sending process and starts the asynchronous thread to calculate the file CRC checksum.

[0030] (5.3) The server points the file pointer to the offset in the task information and starts writing data to the QUIC stream using the zero-copy method; changes the task status to incomplete and persists it in the local database;

[0031] (5.4) The client creates a temporary file to receive the file data, and uses a zero-copy method to write the data directly from the QUIC stream to the temporary file;

[0032] (5.5) After the client writes the data equal to the total file size minus the file offset, it stops writing and sends a message to the server that the transfer is complete.

[0033] (5.6) The server receives the transfer completion message and sends a CRC checksum to the client. After receiving the information, the client compares it with the temporary file. If the check passes, the temporary file is renamed to the official file name and a transfer success message is sent to the server. If the check fails, the temporary file is deleted and a transfer failure message is sent to the server.

[0034] (5.7) The server updates the task status based on the received transmission status message and persists it to the local database; closes the current connection;

[0035] (5.8) After the connection is disconnected, the server changes the task status to interrupted and saves it to the local database;

[0036] (5.9) Obtain the task in interrupt status through sub-step (3.3) and execute step 4;

[0037] (5.10) In sub-step (4.4), modify the file offset of the task metadata information to the total size of the local temporary files that have not been transferred; execute step 5 until the transfer task is completed.

[0038] The present invention also provides a data collaboration system in a multi-satellite weak network scenario based on the QUIC protocol, including:

[0039] The file difference management module is used to provide a difference strategy for the file directories between satellite nodes and filter out the latest version of the files to update the entire constellation;

[0040] The file transfer task management module is used to manage file transfer tasks and is responsible for task submission, transfer status monitoring, and flow control;

[0041] The message communication module is used to implement inter-satellite data communication services and file transfer services.

[0042] The present invention also provides an electronic device, comprising a memory and a processor, wherein the memory is coupled to the processor; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the above-mentioned data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol.

[0043] The present invention also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the data collaboration method in the multi-satellite weak network scenario based on the QUIC protocol is implemented.

[0044] The beneficial effects of the present invention are as follows: the QUIC protocol used in the present invention is a new protocol implemented based on UDP, which has the advantages of fast connection establishment, low latency, multiplexing, high security, etc., and is very suitable for application in satellite network communications. Therefore, the present invention designs and implements message communication and data synchronization mechanisms for multi-satellite weak network environments based on the QUIC protocol. The present invention implements file metadata management and transmission task management based on the HTTP service of QUIC; provides message two-way communication and file transfer functions based on the Socket component of QUIC; and data collaboration services for file synchronization, data migration and message communication. The present invention implements efficient file synchronization, breakpoint resumption and secure integrity verification through key technologies such as file differential management, task management, and message communication modules, thereby ensuring effective and stable data interaction capabilities between satellite nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 It is a system architecture diagram of the present invention;

[0046] Figure 2 is a flow chart of inter-satellite data synchronization in the present invention;

[0047] Figure 3 It is the file transmission data flow diagram of the present invention;

[0048] Figure 4 It is a breakpoint resume flow chart of the present invention;

[0049] Figure 5 is a state transition diagram of a transmission task in the present invention;

[0050] Figure 6 It is a schematic diagram of an electronic device in the present invention. DETAILED DESCRIPTION

[0051] The present invention is described in detail below in conjunction with the accompanying drawings. In the absence of conflict, the features of the following embodiments and implementations can be combined with each other.

[0052] The present invention provides a data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol, and its overall architecture is as follows: Figure 1As shown in the figure, each satellite node deploys a data coordination service (dataserver) to handle the decision of synchronization files and the scheduling of transmission tasks. The data coordination services on the satellite nodes between different satellites implement request-response communication through the QUIC-based httpserver, which is used to request file metadata information of the specified directory from the adjacent satellite node, and submit the task of transmitting files to the target satellite node and obtain the task status. File transfer and message communication between dataservers of different nodes are implemented using QUIC-based socket components. When the system starts, each satellite node starts an http server and socket server.

[0053] See also Figure 2 The data synchronization process between satellite nodes includes the following steps:

[0054] Step 1: Each satellite node starts a QUIC service for file sending and an http3 service based on the QUIC protocol.

[0055] (1.1) Create a QUIC server and register a reader and writer for the server. The Writer implementation encodes any type of message type into the agreed protocol format, adding the magic number, version number, packet type, and packet length as the protocol header; the agreed protocol format is: the magic number is 1 byte, the version number is 4 bytes, the packet type is 1 byte, and the packet length is 4 bytes. The Reader reads data of the specified packet length from the QUIC stream according to the agreed protocol format and decodes it into a message object.

[0056] (1.2) Register a custom stream handler (StreamHandler) for file sending and a message handler (Message Handler) with the QUIC service for incoming message processing and file processing.

[0057] It should be noted that in the metadata acquisition phase, the data collaboration service running on the satellite node provides the ability to schedule synchronization of files in the specified directory. When the scheduled task is started, the file differential management module in the data collaboration service reads the metadata information of the file list in the local directory and sends a file metadata acquisition request to the neighboring nodes at the same time. The destination node traverses all files in the specified directory and returns the file metadata information to the source node. The file metadata is shown in Table 1: When there is a network outage with individual neighboring satellite nodes, this synchronization skips the node and waits for the next task. The current task enters the file comparison phase and executes step 2.

[0058] Table 1: List of file metadata parameters

[0059] Metadata parameters Description Filename file name Path The absolute path to the directory where the file is located NodeIp The node ip where the file is located CreateTime File creation time ModTime File modification time

[0060] Step 2: The satellite node obtains all file metadata of the target directory from the neighboring satellite nodes, and performs differential comparison between the obtained file metadata and the mirror file of the local directory to filter out the list of files to be updated in the local directory and their computing nodes.

[0061] (2.1) Satellite nodes periodically obtain file information from neighboring nodes through a heartbeat mechanism. The heartbeat is implemented by sending file information requests to neighboring nodes every 1-30 seconds (which can be written according to the configuration, the default is 5 seconds).

[0062] (2.2) The comparison strategy between local files and remote files is: filter out the latest files by comparing the latest modification time of the files.

[0063] It should be noted that in the comparison phase, the file difference management module executes the comparison strategy, performs a difference comparison on all the acquired file metadata lists, filters out the latest modified metadata information of each file, and finds the node where the file is located. If it is a local node, it means that the latest version of this file is local and does not need to be synchronized from other nodes; if it is a non-local node, determine whether it is already in the transmission task queue. If not, add it to the queue and go to step 3.

[0064] Step 3: Submit the filtered target file information to the task queue; at the same time, enable the file transfer task to monitor the heartbeat.

[0065] (3.1) Take out the file task list to be synchronized from the task queue, use the snowflake algorithm to generate a unique task ID for each task, and send it to the node where the target file is located;

[0066] (3.2) After receiving the file transfer task, the target node submits it to the sending queue and saves the new transfer task to the local database (DB);

[0067] (3.3) The file transfer task monitoring thread sends heartbeats to the target node at regular intervals (every 1-30 seconds; can be written according to the configuration, the default is 5 seconds) to obtain the file transfer task to be executed; after obtaining the task, start the file receiving client and go to step 4.

[0068] It should be noted that, in the task submission phase, the file metadata information to be synchronized is taken out from the queue and encapsulated as a file transfer task object, whose parameters are shown in Table 2, and the task object is submitted to the target node through the HTTP service; after the target node receives the transfer task, it puts it into the task cache and persists it in the local database, waiting for the source node to initiate a synchronization request and proceed to step 4.

[0069] Table 2: File transfer task metadata information

[0070] Transfer task parameters Parameter Description Taskid The unique ID of the task, generated using the snowflake algorithm in step 3 TaskType Task type, (Upload — send files to the target node / Download — pull files from the target node) NodeIp Target satellite node IP State File transfer task status Filename Transfer file name Savepath Path for storing files after transfer FailNum Number of failed transmissions Offset Offset, start transferring from the file offset Size Total size of the transferred file — bytes

[0071] Step 4: Create a QUIC client for file reception, establish a connection with the QUIC server on the satellite node where the target file is located, and send the task information for file transfer.

[0072] In the file transfer phase, the file sender is used as the server end of the socket, and the file receiver is used as the client end of the file socket. The data flow diagram of the transmission phase is as follows: Figure 3 As shown in the figure, this stage includes the following core processes: task metadata synchronization process, file transfer process, breakpoint resume process (such as Figure 4 ), terminate the transmission process.

[0073] (4.1) Create a QUIC client and register the same Reader and Writer as in substep (1.1) for the client.

[0074] Task metadata synchronization process: The source node sends a transfer task request to the destination node at a fixed time. The destination node reads the local database to obtain the files to be transferred and the unfinished tasks and returns. The source node obtains the file transfer task. If the task status is [BLOCK] / [UNFINISHED] (see Table 3 for task status and Table 3 for state transition mechanism), Figure 5 ), then execute sub-step (4.3) breakpoint resume process; if the task status is [CANCEL], execute sub-step (4.4) transfer termination process; if the task status is [UNSTART], start the file transfer process. Create a Client coroutine for the socket component, and implement the QUIC stream processor and message buffer processor. The connection manager initiates a connection to the Server of the destination node and schedules the stream processor and message processor. After the connection is established, the Client creates a receiving directory, changes the status of the transmission task to [READY], and sends the task metadata to the Server. This process (such as Figure 3 Step 4) First, use the socket component's encoder to encode the task metadata object into a binary stream using the default protocol format, and write it to the QUIC stream through the socket component's Writer. The server reads the data, reads the entire packet of data from the QUIC stream through the socket component's Reader, and uses the decoder to extract the metadata information of the transmission task.

[0075] Table 3: File transfer status description

[0076] Status parameters describe UNSTART Not started - the task is submitted, but the socket connection is not established READY Ready — QUIC connection established, Client and Server ready UNFINISHED Incomplete - The file is being transferred BLOCK Aborted — The connection is lost FINISHED Completed - file transfer completed and CRC check passed FAILED Failure — File transfer failure, including task metadata synchronization failure, temporary file creation failure, write failure, QUIC stream reading failure, CRC check failure, file modification time (modtime) update failure CANCEL Transfer Abort — Stops a file transfer task.

[0077] (4.2) Register a custom data stream handler for file reception with the QUIC client.

[0078] File transfer process: The server uses the zero-copy mechanism to write the file content directly into the QUIC stream for transmission; the client creates a temporary file and uses the zero-copy mechanism to read the size - offset (total file size - file offset) bytes from the QUIC stream and write them into the file.

[0079] (4.3) The QUIC client initiates a connection request to the server. After the connection is established, the data stream processors of the server and the client begin to execute asynchronously, waiting for message communication and file transfer.

[0080] Breakpoint resume process: During the file transfer process, when the connection detection mechanism of the QUIC protocol detects that the connection is disconnected, the server updates the task status to BLOCK and stores it in the local database. When intersatellite communication is restored, the timed request in sub-step (4.1) obtains the task information of this status, creates a Client, reads the temporary file size stored in the task, writes it as the file offset (offset) into the task metadata, and sends it to the server. The metadata sending process is the same as sub-step (4.1).

[0081] (4.4) The QUIC client sends the file transfer task information to the server through Writer, including the unique ID of the transfer task, the task type, the sender node IP, the receiver node IP, the task status, the absolute path of the file, the receiver storage location, whether the file needs to be compressed, the file offset, and the total file size. Among them, the client will change the task status to the ready state before sending the task information.

[0082] Termination of the transmission process: The system receives an instruction to terminate a transmission task and sends a message to the server. The server closes the QUIC connection and changes the status of the transmission task to [CANCLE]. After the client obtains the terminated task in the scheduled task of substep (4.1), it cleans up the local temporary files. After the cleanup is completed, it sends a message to the server to clean up the task from the local database.

[0083] Step 5: The QUIC client of the current node and the QUIC server of the target satellite node start to transfer file data. During the file data transmission process, if the network between satellite nodes fluctuates; if the connection is not disconnected, the retry mechanism is triggered based on the QUIC protocol, and the data is attempted to be resent; if the connection is disconnected, the breakpoint resume mechanism is triggered.

[0084] (5.1) After the server reads the file transfer task sent by the client through Reader, it finds the target file. If the file does not exist, it sends a failure response to the QUIC client and closes the connection;

[0085] (5.2) The server determines whether the task status is ready. If not, it waits for the next message from the client. If it is ready, it enters the file sending process and starts an asynchronous thread to calculate the file CRC checksum.

[0086] (5.3) The server points the file pointer to the offset in the task information and starts writing data to the QUIC stream using the zero-copy method; changes the task status to incomplete and persists it in the local database;

[0087] (5.4) The client creates a temporary file to receive the file data, and uses a zero-copy method to write the data directly from the QUIC stream to the temporary file;

[0088] (5.5) After the client writes (total file size - file offset) data, it stops writing and sends a message to the server indicating that the transfer is complete;

[0089] (5.6) The server receives the transfer completion message and sends a CRC checksum to the client. After receiving the information, the client compares it with the temporary file. If the check succeeds, the temporary file is renamed to the official file name and a transfer success message is sent to the server. If the check fails, the temporary file is deleted and a transfer failure message is sent to the server.

[0090] (5.7) The server updates the task status based on the received transmission status message and persists it to the local database; closes the current connection;

[0091] (5.8) When the connection is disconnected, the server changes the task status to interrupted and saves it to the local database;

[0092] (5.9) Through sub-step (3.3), obtain the task in interrupt status and continue to step 4.

[0093] (5.10) In sub-step (4.4), modify the file offset of the task metadata information to the total size of the local temporary files that have not been transferred; execute step 5 until the transfer task is completed.

[0094] It should be noted that during the data verification phase and the end of the transmission, when sub-step (4.2) is completed, the file is transmitted normally to the end. The server calculates the CRC checksum of the file, encodes the data and sends it to the client. The encoding and transmission process is the same as the file transfer task information sending process in sub-step (4.1). The client calculates the temporary file stored locally and compares it with the received CRC checksum to see if they are consistent. If the verification fails, the task status is changed to [FAILED] and stored in the local database; if the verification succeeds, the creation time (createtime) and modification time (modtime) of the temporary file are modified to be consistent with the sender, the temporary file is renamed to the official file name, overwriting the original file, and the task status is updated to [FINISHED]. At this point, when all files are transferred, the inter-satellite data synchronization task is completed.

[0095] Step 6: After the file transfer is completed, compare it with the received CRC check code; if the comparison is consistent, overwrite the original file and synchronize the file metadata; if the comparison is inconsistent, send a transmission failure message and wait for retransmission.

[0096] The following is an explanation of the technical terms in the present invention:

[0097] HTTP service based on QUIC: provides a service interface for point-to-point request-response mode communications between satellites that carry a small amount of data. This service implements the functions of cross-node file metadata management and transmission task management.

[0098] A QUIC-based socket component that provides an abstract interface for the basic socket required for bidirectional communication of messages and file transfer.

[0099] Data collaboration service: used to provide file synchronization, data migration, and message communication services between satellite nodes.

[0100] Specifically, the socket component includes:

[0101] Server constructor, used to construct a Server based on the QUIC protocol.

[0102] Client constructor, used to construct a Client based on the QUIC protocol.

[0103] Encoders and decoders are used to provide the default communication protocol format, including magic number, version number, packet type, and packet length as the protocol header, and encode and decode the data according to the protocol.

[0104] Writer, used to write data to the QUIC stream.

[0105] Reader, used to read data from the QUIC stream.

[0106] The connection manager is an abstract process that provides a processing strategy for establishing a connection.

[0107] QUIC stream processor, an abstract method provided by the component user and implemented when the Server or Client is constructed, is used to implement the operation methods of the QUIC stream in specific services.

[0108] The message buffer processor is an abstract method provided by the component user and implemented when the Server or Client is constructed. It is used to implement the processing method of the byte buffer generated by sending and receiving messages in the business.

[0109] The present invention provides a data collaboration system in a multi-satellite weak network scenario based on the QUIC protocol, including:

[0110] The file difference management module is used to provide a difference strategy for the file directories between satellite nodes and filter out the latest version of the files for the update of the entire constellation.

[0111] The file transfer task management module is used to manage file transfer tasks and is responsible for task submission, transfer status monitoring, and flow control.

[0112] The message communication module implements inter-satellite data communication services and file transfer services based on the services provided by the above socket component. This module implements the QUIC stream processor and message buffer processor in the socket component for message communication in specific business scenarios.

[0113] Corresponding to the aforementioned embodiment of the data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol, the embodiment of the present application further provides an electronic device, including: one or more processors; a memory for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol as described above. Figure 6 As shown, a hardware structure diagram of any device with data processing capability in the data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol provided in an embodiment of the present application is shown, except Figure 6 In addition to the processor, memory, DMA controller, disk, and non-volatile memory shown, any device with data processing capabilities in which the apparatus in the embodiment is located may also include other hardware, which will not be described in detail, generally based on the actual functions of the device with data processing capabilities.

[0114] Corresponding to the aforementioned embodiment of the data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol, an embodiment of the present invention also provides a computer-readable storage medium on which a program is stored. When the program is executed by a processor, the data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol in the above embodiment is implemented.

[0115] The computer-readable storage medium may be an internal storage unit of any device with data processing capability described in any of the aforementioned embodiments, such as a hard disk or a memory. The computer-readable storage medium may also be any device with data processing capability, such as a plug-in hard disk, a smart media card (SMC), an SD card, a flash card, etc. equipped on the device. Furthermore, the computer-readable storage medium may also include both an internal storage unit of any device with data processing capability and an external storage device. The computer-readable storage medium is used to store the computer program and other programs and data required by any device with data processing capability, and may also be used to temporarily store data that has been output or is to be output.

[0116] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

[0117] The above embodiments are only used to illustrate the design ideas and features of the present invention, and their purpose is to enable those skilled in the art to understand the content of the present invention and implement it accordingly. The protection scope of the present invention is not limited to the above embodiments. Therefore, any equivalent changes or modifications made based on the principles and design ideas disclosed by the present invention are within the protection scope of the present invention.

Claims

1. A data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol, characterized in that: The following steps are involved: Step 1: Start a QUIC service for file sending and an http3 service based on the QUIC protocol on each satellite node; Step 2: The satellite node requests the file metadata of the target directory from the neighboring satellite node, performs a differential comparison between the obtained file metadata and the mirror file of the local directory, and selects the list of files to be updated in the local directory and the computing nodes where they are located; Step 3: Submit the selected target file information to the task queue, and start the file transfer task monitoring heartbeat; Step 4: Create a QUIC client for file reception, establish a connection with the QUIC server on the satellite node where the target file is located, and send the task information of file transfer; Step 5: The QUIC client of the current node and the QUIC server of the target satellite node start transmitting file data; During the file data transmission process, the network between satellite nodes fluctuates; If the connection is not disconnected, the retry mechanism is triggered based on the QUIC protocol, and the data is attempted to be resent; if the connection is disconnected, the breakpoint resume mechanism is triggered; Step 6: After the file transfer is completed, compare it with the received CRC check code; if the comparison is consistent, overwrite the original file and synchronize the file metadata; if the comparison is inconsistent, send a transmission failure message and wait for retransmission.

2. According to the data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol according to claim 1, it is characterized in that: The step 1 includes the following sub-steps: (1.1) Create a QUIC server and register the first reader and the first writer for the server; the first writer encodes the incoming message type of any type into the agreed protocol format, adds the magic number, version number, packet type, and packet length as the protocol header; the first reader reads data of the specified packet length from the QUIC stream and decodes it into a message object; (1.2) Register a first data stream handler and a message handler for file sending with the QUIC service.

3. According to claim 1, the data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol is characterized in that: In step 2, the satellite node periodically obtains the file information of the neighboring nodes through the heartbeat mechanism.

4. According to claim 1, the data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol is characterized in that: In step 2, the obtained file metadata is differentially compared with the mirror file in the local directory, the latest modified metadata information of each file is filtered out, and the node where the file is located is found; If it is a local node, it means that the latest version of this file is local and does not need to be synchronized from other nodes; if it is a non-local node, determine whether it is already in the transmission task queue. If not, add it to the transmission task queue.

5. According to claim 2, the data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol is characterized in that: The step 3 includes the following sub-steps: (3.1) Take out the file task list to be synchronized from the task queue, use the snowflake algorithm to generate a unique task ID for each task, and send it to the node where the target file is located; (3.2) After receiving the file transfer task, the target node submits it to the sending queue and saves the new transfer task to the local database; (3.3) The file transfer task monitoring thread sends heartbeats to the target node at regular intervals to obtain the file transfer tasks to be executed; after obtaining the tasks, the file receiving client is started.

6. The data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol according to claim 5 is characterized in that: The step 4 includes the following sub-steps: (4.1) Create a QUIC client and register a second reader and a second writer for the client; (4.2) Register a second data stream handler for file reception with the QUIC client; (4.3) The QUIC client initiates a connection request to the server. After the connection is established, the data stream processors of the server and the client begin to execute asynchronously, waiting for message communication and file transfer; (4.4) The QUIC client sends information about the file transfer task to the server through the second writer, including the unique ID of the transfer task, the task type, the sender node IP, the receiver node IP, the task status, the absolute path of the file, the receiver storage location, whether the file needs to be compressed, the file offset, and the total size of the file; the client changes the task status to the ready state before sending the task information.

7. The data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol according to claim 6 is characterized in that: The step 5 includes the following sub-steps: (5.1) After the QUIC server reads the file transfer task sent by the client through the first reader, it finds the target file. If the file does not exist, it sends a failure response to the QUIC client and closes the connection; (5.2) The server determines whether the task status is ready. If not, it waits for the next message from the client. If it is in the ready state, the file sending process is entered, and the asynchronous thread is started to calculate the file CRC checksum; (5.3) The server points the file pointer to the offset in the task information and starts writing data to the QUIC stream using a zero-copy method; Change the task status to unfinished and persist it in the local database; (5.4) The client creates a temporary file to receive the file data, and uses a zero-copy method to write the data directly from the QUIC stream to the temporary file; (5.5) After the client writes the data equal to the total file size minus the file offset, it stops writing and sends a message to the server that the transfer is complete. (5.6) The server receives the transfer completion message and sends a CRC checksum to the client. After receiving the information, the client compares it with the temporary file. If the check passes, the temporary file is renamed to the official file name and a transfer success message is sent to the server. If the verification fails, the temporary file is deleted and a transmission failure message is sent to the server; (5.7) The server updates the task status based on the received transmission status message and persists it to the local database; closes the current connection; (5.8) After the connection is disconnected, the server changes the task status to interrupted and saves it to the local database; (5.9) Obtain the task in interrupt status through sub-step (3.3) and execute step 4; (5.10) In sub-step (4.4), modify the file offset of the task metadata information to the total size of the local temporary files that have not been transferred; execute step 5 until the transfer task is completed.

8. A data collaboration system in a multi-satellite weak network scenario based on the QUIC protocol that implements the method as claimed in claim 1, characterized in that: include: The file difference management module is used to provide a difference strategy for the file directories between satellite nodes and filter out the latest version of the files to update the entire constellation; The file transfer task management module is used to manage file transfer tasks and is responsible for task submission, transfer status monitoring, and flow control; The message communication module is used to implement inter-satellite data communication services and file transfer services.

9. An electronic device, comprising a memory and a processor, characterized in that: The memory is coupled to the processor; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol as described in any one of claims 1-7 above.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by the processor, the data collaboration method in a multi-satellite weak network scenario based on the QUIC protocol is implemented as described in any one of claims 1 to 7.

Images