A ship-shore narrowband network data dynamic synchronization method, device, equipment and medium

Abstract

The application discloses a ship-shore narrowband network data dynamic synchronization method and device, equipment and medium, obtains bitmap information of a first end and a second end; adjusts a sending window of a data packet according to a continuous state of interaction information between the first end and the second end; determines transmission data of the data packet through the sending window based on the bitmap information; concurrently transmits the transmission data of each data packet of the first end to the second end; obtains receiving feedback of the transmission data in response of the second end, updates the bitmap information according to the receiving feedback; wherein, the transmission data is merged into historical transmission data, and the receiving feedback is merged into historical receiving feedback; returns to execute the step of adjusting the sending window of the data packet according to the continuous state of the interaction information between the first end and the second end until a file to be synchronized is completed data synchronization. The application can efficiently realize ship-shore narrowband network data dynamic synchronization, and can be widely applied to the technical field of data processing.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and in particular to a ship-shore narrowband network data dynamic synchronization method, device, equipment and medium. BACKGROUND

[0002] Under the background of increasing data exchange demand between ships and land, the data synchronization technology from the ship end to the shore end has become a key link to ensure real-time information transmission and business continuity. At present, TCP (Transmission Control Protocol) is widely used as the basic communication mechanism for data synchronization in this field, which follows the mature practice of data synchronization between two points on land. By building a stable and reliable TCP communication channel, efficient data transmission between the ship end and the shore end is achieved.

[0003] The existing data synchronization process from the ship end to the shore end is usually carefully divided into three stages: metadata preparation, data synchronization, and final verification. This process design aims to ensure the systematicness and integrity of the data synchronization process. In the metadata preparation stage, the system will preprocess the data to be synchronized and generate the necessary metadata information to lay the foundation for subsequent data transmission and verification. Subsequently, the data synchronization stage is entered, the core of which is to use a fixed window sending strategy to adapt to the dynamic changes of the network environment by accurately controlling the size and frequency of the sending window, ensuring that the data can be stably and orderly transmitted to the target end.

[0004] However, although the existing technology meets the basic needs of data synchronization from the ship end to the shore end to some extent, its limitations gradually appear when faced with large-scale data synchronization tasks or complex and variable network environments. Although the fixed window sending strategy improves transmission efficiency to some extent, it may cause data transmission delay or interruption in the case of large network fluctuations, affecting the real-time and reliability of synchronization. In addition, with the continuous increase of data volume, how to further optimize the transmission strategy, improve resource utilization, and ensure the integrity and accuracy of data has become a problem to be solved in the current technology. SUMMARY

[0005] The present application aims to at least partially solve the limitations of the related art. To this end, the present application provides a ship-shore narrowband network data dynamic synchronization method, device, equipment and medium, which can efficiently perform ship-shore narrowband network data dynamic synchronization.

[0006] In one aspect, the present application embodiment provides a ship-shore narrowband network data dynamic synchronization method, comprising:

[0007] Obtaining bitmap information of the first end and the second end; the bitmap information includes the bitmap position and synchronization state of all data blocks under each data packet in the to-be-synchronized file;

[0008] adjusting the sending window of the data packet according to a continuous state of the interaction information between the first end and the second end;

[0009] The interaction information comprises transmission information and feedback information; the transmission information comprises historical transmission data sent by the first end to the second end and a heartbeat request sent periodically; the feedback information comprises historical receiving feedback in response to the historical transmission data and a heartbeat reply in response to the heartbeat request.

[0010] The transmission data of the data packet is determined through the sending window based on the bitmap information;

[0011] The transmission data of each data packet of the first end is transmitted to the second end concurrently;

[0012] The receiving feedback of the second end in response to the transmission data is obtained, and the bitmap information is updated according to the receiving feedback;

[0013] The transmission data is merged into the historical transmission data, and the receiving feedback is merged into the historical receiving feedback.

[0014] The step of adjusting the sending window of the data packet according to the continuous state of the interaction information between the first end and the second end is returned to be executed until the data synchronization of the file to be synchronized is completed.

[0015] Optionally, the method further comprises the following steps:

[0016] The file to be synchronized is split into a plurality of data blocks based on a preset transmission protocol, and then the block ID of each data block is sequentially marked;

[0017] Based on a preset packet size, the corresponding data block is obtained from the file to be synchronized in the order of the block ID from small to large, and then the packet ID of each data packet is sequentially marked;

[0018] The block ID and the preset packet size are subjected to a remainder operation to obtain the grouping position of each data block in the corresponding data packet;

[0019] The bitmap position of each data block is determined based on the packet ID and the grouping position.

[0020] Optionally, the continuous state comprises continuity and a sequence number difference value, and the continuity comprises continuity or discontinuity; adjusting the sending window of the data packet according to the continuous state of the interaction information between the first end and the second end comprises the following steps:

[0021] The latest data sent by the first end is obtained from the historical transmission data as target transmission data, and the latest data responded by the second end is obtained from the historical receiving feedback as target receiving feedback;

[0022] The first end latest sent heartbeat request is taken as a target heartbeat request, and the second end latest responded heartbeat reply is taken as a target heartbeat reply;

[0023] According to the target transmission data and the Seq sequence number carried by the target receiving feedback, a first continuous state is determined; the first continuous state includes first continuity and a first sequence number difference value;

[0024] According to the Seq sequence number carried by the heartbeat request and the heartbeat reply, a second continuous state is determined; the second continuous state includes second continuity and a second sequence number difference value;

[0025] Based on the first continuous state or the second continuous state, the window size of the sending window is adjusted.

[0026] Optionally, based on the first continuous state or the second continuous state, the window size of the sending window is adjusted, including at least one of the following steps:

[0027] When the first continuity is continuous, the window size is expanded; otherwise, the first sequence number difference value is determined; when the first sequence number difference value is greater than a preset difference threshold value, the window size is reduced; otherwise, the window size is not adjusted;

[0028] When the second continuity is continuous, the window size is not adjusted; otherwise, the window size is reduced;

[0029] The expansion processing includes doubling expansion, step-by-step expansion and no expansion, and the reduction processing includes halving reduction and step-by-step reduction; the manner of the expansion processing and the reduction processing is determined based on the window size before the sending window is adjusted.

[0030] Optionally, the receiving feedback includes a bitmap position of a data block completed to be received; the bitmap information is updated according to the receiving feedback, including the following steps:

[0031] Based on the bitmap position, the data block included in the transmission data is compared with the data block completed to be received included in the receiving feedback, to determine a target data block completed to be synchronized;

[0032] The synchronization state of the target data block is updated to be completed to be synchronized.

[0033] Optionally, the method further includes the following steps:

[0034] The second end responds to the receiving information to reply the data block receiving situation to the first end regularly;

[0035] The receiving information includes a block check request and a heartbeat request sent by the first end regularly;

[0036] The bitmap information is secondarily updated based on the data block receiving situation.

[0037] Optionally, the method further comprises at least one of the following steps:

[0038] The first check information of the transmission data is acquired, the second check information is calculated by checking the first synchronization data of the second end in response to the completion of the synchronization of the transmission data, and the first check is performed based on the first check information and the second check information.

[0039] When the result of the first check is inconsistent, the first retransmission feedback is performed to the first end.

[0040] The third check information of the to-be-synchronized file is acquired, the fourth check information is calculated by checking the second synchronization data of the second end in response to the completion of the synchronization of the to-be-synchronized file, and the second check is performed based on the third check information and the fourth check information.

[0041] When the result of the second check is inconsistent, the second retransmission feedback is performed to the first end.

[0042] In another aspect, an embodiment of the present application provides a ship-shore narrowband network data dynamic synchronization device, comprising:

[0043] The first module is configured to acquire bitmap information of the first end and the second end, wherein the bitmap information comprises bitmap positions and synchronization states of all data blocks under each data packet in the to-be-synchronized file.

[0044] The second module is configured to adjust a sending window of the data packet according to a continuous state of interactive information between the first end and the second end.

[0045] The interactive information comprises transmission information and feedback information, wherein the transmission information comprises historical transmission data sent by the first end to the second end and a heartbeat request sent periodically, and the feedback information comprises historical receiving feedback in response to the historical transmission data and a heartbeat reply in response to the heartbeat request.

[0046] The third module is configured to determine transmission data of the data packet based on the bitmap information and the sending window.

[0047] The fourth module is configured to concurrently transmit the transmission data of each data packet of the first end to the second end.

[0048] The fifth module is configured to acquire receiving feedback of the second end in response to the transmission data, and update the bitmap information according to the receiving feedback.

[0049] The transmission data is merged into the historical transmission data, and the receiving feedback is merged into the historical receiving feedback.

[0050] The sixth module is configured to return to execute the second module until the data synchronization of the to-be-synchronized file is completed.

[0051] Optionally, the device further comprises:

[0052] The seventh module is configured to split the file to be synchronized into a plurality of data blocks based on a preset transmission protocol, and sequentially mark a block ID of each data block;

[0053] The eighth module is configured to obtain a corresponding data block from the file to be synchronized in a direction from small to large along the block ID based on a preset group size to construct a data group, and sequentially mark a group ID of each data group;

[0054] The ninth module is configured to perform a remainder operation on the block ID and the preset group size to obtain a group position of each data block in the corresponding data group;

[0055] The tenth module is configured to determine a bitmap position of each data block based on the group ID and the group position.

[0056] Optionally, the apparatus further comprises:

[0057] The eleventh module is configured to periodically reply, by the second end, to the first end about a data block receiving situation in response to receiving information;

[0058] The receiving information comprises a block check request and a heartbeat request periodically sent by the first end;

[0059] The twelfth module is configured to perform secondary update on the bitmap information based on the data block receiving situation.

[0060] Optionally, the apparatus further comprises at least one of the following:

[0061] The thirteenth module is configured to obtain first check information of the transmission data, to check and calculate second check information of first synchronization data of the second end in response to completion of synchronization of the transmission data, and to perform first check based on the first check information and the second check information.

[0062] When the result of the first check is inconsistent, the first end is fed back with first retransmission.

[0063] The fourteenth module is configured to obtain third check information of the file to be synchronized, to check and calculate fourth check information of second synchronization data of the second end in response to completion of synchronization of the file to be synchronized, and to perform second check based on the third check information and the fourth check information.

[0064] When the result of the second check is inconsistent, the first end is fed back with second retransmission.

[0065] In another aspect, an electronic device is provided, comprising a processor and a memory, the memory is configured to store a program, and the processor is configured to execute the program to implement the above-mentioned ship-shore narrowband network data dynamic synchronization method.

[0066] In another aspect, the embodiments of the present application provide a computer storage medium, which stores a processor-executable program, and the processor-executable program, when executed by a processor, is used to implement the above-mentioned ship-shore narrowband network data dynamic synchronization method.

[0067] The embodiments of the present application obtain bitmap information of the first end and the second end, the bitmap information including bitmap positions and synchronization states of all data blocks under each data packet in the file to be synchronized; adjust a sending window of the data packet according to a continuous state of interactive information between the first end and the second end, wherein the interactive information includes transmission information and feedback information, the transmission information including historical transmission data sent by the first end to the second end and a heartbeat request sent periodically, and the feedback information including historical receiving feedbacks in response to the historical transmission data and heartbeat replies in response to the heartbeat request; determine transmission data of the data packet based on the bitmap information through the sending window; concurrently transmit the transmission data of each data packet of the first end to the second end; obtain receiving feedbacks of the second end in response to the transmission data, and update the bitmap information according to the receiving feedbacks; and return to the step of adjusting the sending window of the data packet according to the continuous state of the interactive information between the first end and the second end until the file to be synchronized is completed with data synchronization. The embodiments of the present application can accurately grasp the bitmap positions and the synchronization states of all data blocks under each data packet in the file to be synchronized by comprehensively obtaining and updating the bitmap information of the first end and the second end in real time. This mechanism effectively avoids data duplication and omission, and significantly improves the accuracy of data synchronization. Meanwhile, the dynamic sending window adjustment strategy based on the bitmap information can flexibly cope with changes in network conditions, ensure data transmission under optimal conditions, and thus improve synchronization efficiency. The present application can efficiently implement ship-shore narrowband network data dynamic synchronization. BRIEF DESCRIPTION OF DRAWINGS

[0068] The accompanying drawings are included to provide a further understanding of the technical scheme of the present application, and constitute a part of the specification, and are used together with the embodiments of the present application to explain the technical scheme of the present application, and do not constitute a limitation on the technical scheme of the present application.

[0069] Figure 1 An implementation environment diagram for performing ship-shore narrowband network data dynamic synchronization is provided for the embodiments of the present application;

[0070] Figure 2 A flowchart of a ship-shore narrowband network data dynamic synchronization method is provided for the embodiments of the present application;

[0071] Figure 3 An extended flowchart of a ship-shore narrowband network data dynamic synchronization method is provided for the embodiments of the present application;

[0072] Figure 4 An expansion flow diagram for adjusting a sending window provided for an embodiment of the present application is shown in FIG. 1.

[0073] Figure 5 An expansion flow diagram for updating bitmap information provided for an embodiment of the present application is shown in FIG. 6.

[0074] Figure 6 An expansion flow diagram for updating bitmap information provided for an embodiment of the present application is shown in FIG. 6.

[0075] Figure 7 An expansion flow diagram for updating bitmap information provided for an embodiment of the present application is shown in FIG. 6.

[0076] Figure 8 An expansion flow diagram for updating bitmap information provided for an embodiment of the present application is shown in FIG. 6.

[0077] Figure 9 An expansion flow diagram for updating bitmap information provided for an embodiment of the present application is shown in FIG. 6.

[0078] Figure 10 An expansion flow diagram for updating bitmap information provided for an embodiment of the present application is shown in FIG. 6. DETAILED DESCRIPTION

[0079] In order to make the objectives, technical solutions and advantages of the present application clearer, the present application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and do not limit the present application.

[0080] It should be noted that although the functional modules are divided in the system schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than the module division in the system or the order in the flowchart. The terms "first / S100", "second / S200" and the like in the specification and claims and the above-described drawings are used to distinguish similar objects and do not necessarily describe a specific order or sequence.

[0081] In the present application, the term "embodiment" means that the specific features, structures or characteristics described in conjunction with the embodiment can be included in at least one embodiment of the present application. The phrase appears in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment independent of or alternative to other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described in the present application can be combined with other embodiments.

[0082] It can be understood that the ship-shore narrowband network data dynamic synchronization method provided by the embodiment of the present application can be applied to any computer device with data processing and calculation capability, and the computer device can be various terminals or servers. When the computer device in the embodiment is a server, the server is an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and basic cloud computing services such as big data and artificial intelligence platforms. Alternatively, the terminal is a smart phone, a tablet computer, a notebook computer, and a desktop computer, but is not limited thereto.

[0083] In order to facilitate the understanding of the technical solutions of the present application, the technical features of the present application will be explained first.

[0084] VSAT satellite communication (Very Small Aperture Terminal): VSAT is derived from the traditional satellite communication system, so it is also called satellite small data station or personal earth station. Here, "small" refers to the small aperture of the antenna of the small station equipment in the VSAT system, usually 0.3m-1.4m, the equipment structure is compact, solid, intelligent, cheap, easy to install, and has low requirements on the use environment, and is not limited by the ground network, and the networking is flexible.

[0085] Drilling vessel (Drilling Vessel) is a ship specially used for drilling operation on seabed geological structure, mainly used for marine geological exploration. With the in-depth implementation of the national marine strategy, China's drilling and mining vessels appear more and more frequently in the international oceans such as the Pacific Ocean, at this time the communication means between the ship and the shore base is only satellite.

[0086] TCP transmission control protocol (Transmission Control Protocol) is a connection-oriented, reliable, byte stream-based transport layer communication protocol. TCP aims to adapt to the layered protocol hierarchy supporting multi-network applications. The pair of processes in the host computer connected to different but interconnected computer communication networks rely on TCP to provide reliable communication services. TCP assumes that it can obtain simple, possibly unreliable datagram services from lower-level protocols. In principle, TCP should be able to operate on various communication systems from hard-wired connections to packet switching or circuit switching networks.

[0087] UDP (User Datagram Protocol) is a connectionless, unreliable datagram-based transport mechanism that only provides encapsulation of source port, destination port, data length, and checksum, enabling fast and simple end-to-end communication. It does not guarantee the ordered arrival, reliable transmission, or flow control of data, making it suitable for scenarios that are sensitive to delay, can tolerate packet loss, and have self-correction capabilities, such as real-time audio and video streaming, online gaming, network broadcasting, DNS queries, etc.

[0088] LZMA Compression Algorithm: In actual compression algorithms, LZMA (Lempel-Ziv-Markov chain Algorithm) is generally considered to provide extremely high compression rates. It was proposed in 1998 and is an improved version of the LZ77 algorithm, used to implement the 7-Zip file format (.7z). LZMA uses a chained compression method and applies a modified LZ77 algorithm at the bit level to achieve excellent compression efficiency, especially when dealing with text, source code, and other data with high repetition.

[0089] LZMA2 Compression Algorithm: As a successor to LZMA, LZMA2 further improves compression performance and multi-core processor support while maintaining high compression rates. In practical applications, such as using 7-Zip software, selecting the LZMA2 compression method often results in very high compression rates.

[0090] MD5 (Message-Digest Algorithm 5): It is a widely used cryptographic hash function designed to convert information of any length into a fixed-length hash value. This process is one-way, meaning it is difficult to reverse the original information from the hash value. The core significance of MD5 lies in providing a data verification mechanism. By calculating the MD5 value of the data, it can efficiently compare whether the data is consistent without directly comparing the data itself. It is achieved through complex mathematical operations, so even a small change in data will result in a significant difference in the calculated MD5 value.

[0091] As shown in Figure 1 , it is an implementation environment schematic diagram provided by the application embodiment. Referring to Figure 1 , the implementation environment includes at least one terminal 102 and a server 101. The terminal 102 and the server 101 can be connected through wireless or wired means for network connection to complete data transmission and exchange.

[0092] Server 101 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0093] Additionally, server 101 can also be a node server in a blockchain network. Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms.

[0094] Terminal 102 can be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. Terminal 102 and server 101 can be directly or indirectly connected via wired or wireless communication, and this embodiment of the invention does not impose any limitations.

[0095] Exemplary based on Figure 1 The implementation environment shown in this embodiment of the invention provides a method for dynamic synchronization of ship-to-shore narrowband network data. The following description uses the application of this method in server 101 as an example. It can be understood that this method can also be applied in terminal 102.

[0096] Reference Figure 2 , Figure 2 This is a flowchart illustrating a method for dynamic data synchronization in a ship-to-shore narrowband network applied to a server, provided in an embodiment of the present invention. The executing entity of this method can be any of the aforementioned computer devices (including a server or a terminal). (Refer to...) Figure 2 The method includes the following steps:

[0097] S100. Obtain bitmap information from the first and second ends; the bitmap information includes the bitmap position and synchronization status of all data blocks under each data group in the file to be synchronized.

[0098] The synchronization status includes: synchronization completed, synchronization in progress, and waiting for synchronization.

[0099] In some specific embodiments, the present invention further includes a step of local data compression, which can be implemented as follows:

[0100] There are generally many files to be transmitted at the ship end, mainly test results of technical experiments, including table, text, picture and high-definition video files. These data files need to be compressed before transmission. The application adopts the open source LZMA2 compression algorithm, which has a very high compression rate. Compared with other compression algorithms, the compression speed is slightly slower, but considering the satellite bandwidth, the higher compression rate is still necessary. In the data transmission management regulations on the ship, it is not recommended to transmit high-definition videos. This is because the current videos are usually in compressed format, and even if LZMA2 is used for further compression, the file compression rate will not be too high, and the video will occupy a large amount of bandwidth to affect the transmission of other files, so the high-definition video files are usually synchronized by direct copying after the ship docks.

[0101] Under normal circumstances, there are multiple files to be synchronized, which are sorted by the last modification time, and the files are divided into multiple groups for compression. The application divides the groups according to 100M as the benchmark, that is, the sum of the file sizes of each group is about 100M, and if a single file exceeds 100M, the file is grouped alone. Then each group is compressed, and the compressed package name is the MD5 of the sum of all file names. In this way, a series of compressed packages are obtained. This grouping standard can be customized and adjusted, but it is not recommended to exceed 200M, because the larger the compressed file, the higher the file transmission failure rate. These compressed packages are transmitted synchronously one by one, and the application is for single compressed package data synchronization.

[0102] In most cases, the text invention file compression rate can reach about 60%, that is, the size of the compressed text invention file is about 40% of the original size, and according to the 100M grouping, the size of a single compressed package is about 40M. In actual scenarios, the compression rate can even reach 70%.

[0103] It should be understood that in the case of using data local compression means, the verification information transmitted can include the file name, file size, file MD5, file creation time, last modification time, bitmap grouping and other information of the compressed package. These information are mainly used to determine whether breakpoint resume is needed.

[0104] In some embodiments, for example, Figure 3As shown, the method can further include the following steps: T100, splitting the file to be synchronized into a plurality of data blocks based on a preset transmission protocol, and then sequentially marking a block ID of each data block; T200, based on a preset grouping size, sequentially obtaining a corresponding data block from the file to be synchronized along the direction of increasing block ID to construct a data group, and then sequentially marking a group ID of each data group; T300, performing a remainder operation on the block ID and the preset grouping size to obtain a grouping position of each data block in the corresponding data group; and T400, determining a bitmap position of each data block based on the group ID and the grouping position.

[0105] Exemplarily, in some embodiments, when the shore end receives the data synchronization request, the file transmitted by the shore end is checked, and the process is mainly as follows:

[0106] 1) The file name is checked to check whether the file exists in the shore end. If not, it indicates that the file is transmitted for the first time. If not, the MD5 of the file is compared.

[0107] 2) The file MD5 is checked to check whether the MD5 of the file in the shore end is consistent with the MD5 of the target file. If not, it indicates that the target file has changed, and needs to be retransmitted. If consistent, the file size is compared.

[0108] 3) The bitmap information of the present application and the file size are checked. If consistent, it indicates that the file has been transmitted before, and the breakpoint resume transmission can be selected. If not consistent, it indicates that the target file has changed, and needs to be retransmitted. This step is necessary because the file is stored in the cache area before the transmission is successful, and the cache may be tampered or cleared.

[0109] 4) The bitmap information of all groups is checked. If all data packets have been received, it indicates that the data synchronization is successful, otherwise, the transmission from the beginning or the breakpoint resume transmission is needed. If the data has been successfully transmitted, the final check flag of the shore end is checked. If the check has been completed, the ship end is replied that the synchronization is successful, otherwise, the final check is replied to be needed.

[0110] The bitmap information is used to mark the receiving condition of the file in the shore end, and the present application uses a two-level bitmap. Simply, the file to be transmitted is divided into groups according to the SubSize, and the bitmap of each group is calculated separately. Referring to the following formula, FileSize is the file size, SubSize is the grouping size, ArraySize calculated by formula (1) is the number of groups (the calculation result is rounded up), PacketSize is the data block size, and BitMapSize calculated by formula (2) is the bitmap size of each group.

[0111]

[0112] So the bitmap size of each packet is bytes, each position of the bitmap is 0 if no data is received, and 1 if data is received. For each block ID, its corresponding packet ID can be calculated by formula (3), and its position in the bitmap can be calculated by formula (4) in the corresponding packet:

[0113]

[0114] ArrayIndex = ID % ArraySize (4)

[0115] Compared with the primary bitmap, the biggest change of the secondary bitmap is that it is cut into multiple sub-bitmaps, which is done to facilitate the concurrent transmission of multiple packet data, and this feature is one of the core points of the present application and cannot be achieved by previous work.

[0116] S200, adjusting a sending window of a data packet according to a continuous state of interaction information between the first end and the second end;

[0117] The interaction information includes transmission information and feedback information; the transmission information includes historical transmission data sent by the first end to the second end and a heartbeat request sent periodically; the feedback information includes historical receiving feedback in response to the historical transmission data and a heartbeat reply in response to the heartbeat request;

[0118] It should be noted that the continuous state includes continuity and a sequence number difference value, and the continuity includes continuity or discontinuity; in some embodiments, as shown in Figure 4 S201, obtaining the latest data sent by the first end as target transmission data from the historical transmission data, and obtaining the latest data responded by the second end as target receiving feedback from the historical receiving feedback; S202, taking the latest heartbeat request sent by the first end as a target heartbeat request, and taking the latest heartbeat reply responded by the second end as a target heartbeat reply; S203, determining a first continuous state according to the Seq sequence number carried by the target transmission data and the target receiving feedback; the first continuous state includes a first continuity and a first sequence number difference value; S204, determining a second continuous state according to the Seq sequence number carried by the heartbeat request and the heartbeat reply; the second continuous state includes a second continuity and a second sequence number difference value; S205, adjusting the window size of the sending window based on the first continuous state or the second continuous state.

[0119] In some embodiments, the window size of the sending window is adjusted based on a first continuous state or a second continuous state, including at least one of the following steps: when the first continuity is continuous, the window size is expanded; otherwise, a first sequence number difference is determined; when the first sequence number difference is greater than a preset difference threshold, the window size is shrunk; otherwise, the window size is not adjusted; when the second continuity is continuous, the window size is not adjusted; otherwise, the window size is shrunk; wherein, the expansion process includes doubling expansion, step expansion, and no expansion, and the shrinking process includes halving shrinking and gradual shrinking; the expansion and shrinking processes are determined based on the window size before the sending window is adjusted.

[0120] In some embodiments, the number of windows that can be adjusted may be limited, especially when the window is expanded, to prevent potential momentary network congestion.

[0121] For example, in some specific implementations, each group has its own sending window, meaning different groups can be transmitted concurrently, thus achieving simultaneous transmission of multiple data streams, which is one of the core points of this invention. Assuming the maximum concurrent number of groups is ParallelNum (which can be customized, at least 1, and typically configured as 3-5), that is, a maximum of three groups can be transmitted concurrently. The sending window of each group is dynamically calculated and adjusted, and the adjustment method is consistent across different groups. Therefore, this description focuses on the window adjustment method from the perspective of a single group.

[0122] The window size, WindowSize, starts at 1. Each time a response is received from the shore, the window either doubles in size (see Formula 5) or halves in size (see Formula 8). When the window exceeds the intermediate threshold, MidSize, the window size increases by 1 each time it expands (see Formula 6), instead of doubling; and the window size decreases by 1 each time it shrinks (see Formula 9), instead of halving. When the window exceeds the maximum threshold, FinSize, it stops growing; this is the maximum threshold (see Formula 7).

[0123] WindowSize=WindowSize*2, WindowSize <MidSize (5)

[0124] WindowSize=WindowSize+1, FinSize>WindowSize≥MidSize (6)

[0125] WindowSize=WindowSize, WindowSize≥FinSize (7)

[0126]

[0127] WindowSize=WindowSize-1, WindowSize≥MidSize (9)

[0128] The intermediate threshold value MidSize and the maximum threshold value FinSize can be customized, and are generally determined based on network communication bandwidth and practical experience. In scenarios based on ship-to-shore data synchronization, through extensive testing, MidSize is typically 8 and FinSize is typically 12.

[0129] For a group, the operation of expanding or shrinking the window is mainly based on the following rules:

[0130] Case 1: When the data packet is received in chunks from the shore, if the Seq sequence numbers are consecutive, it indicates that the data was received successfully very quickly, and the window expands. Here, consecutive Seq sequence numbers mean that if the ship sends Seq1 and the shore replies with Seq1+1, it can be considered consecutive.

[0131] Case 2: When the data packet is received in chunks from the shore, if the Seq sequence number is not consecutive, but the Seq difference does not exceed MaxSeqLen (which can be customized and is set to 2 by default), it indicates that the data reception is normal and the window remains unchanged.

[0132] Case 3: When the data packet is received in chunks from the shore, if the Seq sequence number is not consecutive, but the Seq difference exceeds MaxSeqLen, it indicates that the data reception is somewhat blocked, and the window is reduced.

[0133] Case 4: When the packet receives a heartbeat response from the shore, if the Seq sequence number is consecutive, the window remains unchanged. Normally, the heartbeat frequency is once per second, which is a bit slow to reflect network latency, so the window is kept constant here.

[0134] Case 5: When a heartbeat response is received from the shore, if the sequence number is discontinuous, the window size should be reduced. Discontinuous heartbeat sequences indicate severe network congestion, necessitating window size reduction.

[0135] Case 6: When multiple transmission packets exist (i.e., ArraySize ≥ 2), and a new packet is started to participate in transmission after one packet has been transmitted. In this case, all packets compete for the window expansion opportunity, and the number of window expansion opportunities does not exceed half the number of packets. First come, first served; that is, the first group to request window expansion will have its window expanded, while the windows of other groups remain unchanged. If all group windows were expanded, it could cause momentary network congestion, so window expansion here is a competitive process.

[0136] Case7: When the bitmap is updated, if a suspected packet loss occurs and the number of suspected packet losses does not exceed MaxLostNum (which can be configured by default, and the default value is 3), the window remains unchanged.

[0137] Case8: When the bitmap is updated, if a suspected packet loss occurs and the number of suspected packet losses exceeds MaxLostNum, the window is reduced.

[0138] Case9: If the above several situations are encountered at the same time, if they are all window expansion operations or expansion operations and remain unchanged, the window is expanded once, if they are all window reduction operations or reduction operations and remain unchanged, the window is reduced once, and otherwise the window remains unchanged.

[0139] In general, the sending window is dynamically adjusted based on multiple conditions. When a data receiving reply, a heartbeat reply, an updated bitmap, and the like are received, the window is dynamically adjusted. Based on the dynamic window adjustment strategy, flexible data transmission control is achieved, thereby improving the transmission speed.

[0140] S300, based on the bitmap information, determining the transmission data of the data packets by the sending window;

[0141] If the sending window is expanded, the data chunks in the waiting synchronization are further included in the sending window, and the synchronization state of the corresponding data chunk is changed to synchronization in progress. Similarly, if the sending window is reduced, the data chunk at the rear of the bitmap in the synchronization is removed from the sending window, and the synchronization state of the corresponding data chunk is changed to waiting synchronization. Correspondingly, the present embodiment can adopt out-of-order transmission.

[0142] S400, concurrently transmitting the transmission data of each data packet of the first end to the second end;

[0143] Exemplarily, in some specific embodiments, the present embodiment can adopt out-of-order transmission, and the following can be implemented:

[0144] Out-of-order sending of data chunks:

[0145] For single-group data transmission, if the data of the group still exists part that has not been synchronized, the out-of-order sending of data chunks is prepared. Referring to Figure 5 , the state of the data is divided into three states of synchronization in progress, waiting synchronization, and completed synchronization. It can be seen that group 01 has been synchronized and completed, groups 02-06 are in synchronization, and the data block 03 of group 02 is suspected to be lost and is currently being re-sent.

[0146] The window of each group is dynamically calculated, if the number of data blocks in synchronization state SyningNum is less than the current sending window size WindowSize (i.e. SyningNum < WindowSize), the data is selected to be sent or retransmitted.

[0147] If the number of data blocks in synchronization state SyningNum is not less than the current sending window size WindowSize (i.e. SyningNum >= WindowSize), the current state is kept unchanged. When it is determined that a certain data packet is suspected to be lost, the state of the data is modified to be synchronized, at this time the number of synchronization state data packets is reduced, SyningNum = SyningNum-1. The operation is continuously performed until SyningNum == WindowSize, and then the operation is stopped.

[0148] How to determine that a certain data packet is suspected to be lost? If the state of the data block processing synchronization is received, and the SeqID of the bitmap update exceeds the SeqID of the data block sent, the data block is suspected to be lost.

[0149] Unlike the existing method, the application regards the retransmitted data packet and other data packets as the same, and sends data as long as there is a seat in the sending window. If the sending window is full, the sending is stopped, at this time the data suspected to be lost will not be retransmitted until there is a seat in the window.

[0150] The data blocks are received in disorder and stored in order:

[0151] The shore end receives multiple UDP data packets, including file ID, block ID, data block, SeqID and other information. According to the file ID, it is determined which file the data is, and according to the block ID, the block position is determined. Based on the block ID, ArrayID is calculated by formula (3), and ArrayIndex is calculated by formula (4), that is, the specific position in the group is determined.

[0152] Considering the network factors and breakpoint retransmission, the data packets received by the shore end may not arrive in order, but the shore end will store them in order according to the block ID, and the temporarily not received data is the "breakpoint" data. At the same time, the shore end may receive multiple data packets with the same file ID and block ID, if it has been saved, the repeated data packets are directly discarded.

[0153] Reference Figure 6 Data sending process, the repeated sending of data by the ship end and the receiving of data by the shore end in normal case easily affects the transmission efficiency, therefore, the ship end of the application dynamically adjusts the sending window to adjust the sending rhythm, the shore end regularly checks the data and replies to the ship end. When the data loss is determined, the ship end retransmits the data according to the sending window to realize the breakpoint resume.

[0154] S500, updating the bitmap information according to the receiving feedback of the second end in response to the transmission data;

[0155] wherein the transmission data is merged into historical transmission data, and the receiving feedback is merged into historical receiving feedback;

[0156] It should be noted that the receiving feedback includes the bitmap position of the data block completed receiving; in some embodiments, as shown in Figure 7 updating the bitmap information according to the receiving feedback can include the following steps: S501, comparing the data block included in the transmission data with the data block completed receiving included in the receiving feedback based on the bitmap position, to determine the target data block completed synchronization; S502, updating the synchronization state of the target data block to completed synchronization.

[0157] S600, returning to execute the step of adjusting the sending window of the data block group according to the continuous state of the interaction information between the first end and the second end until the file to be synchronized is completed data synchronization.

[0158] In some embodiments, the method can further include the following steps: the second end responds to the receiving information to reply the data block receiving situation to the first end periodically; wherein the receiving information includes the block check request and the heartbeat request sent periodically by the first end; and the bitmap information is updated again based on the data block receiving situation.

[0159] Exemplarily, in some specific embodiments, the data block receiving situation can be replied periodically, and the specific implementation can be as follows:

[0160] The shore end will receive a large number of data packets in succession and store them in sequence. When the shore end meets the following conditions, it will immediately reply the data block receiving situation:

[0161] Case1: reply the data block receiving situation every time data is received.

[0162] Case2: reply the data block receiving situation immediately when the block check request is received.

[0163] Case3: reply the data block receiving situation immediately when the heartbeat request is received.

[0164] It should be noted that multiple groups send data blocks concurrently, and in most cases, the shore end will receive multiple packets at the same time, process the received data first, and then reply the received bitmap information of the related group. Through most experiments, it is often found that one reply packet replies the receiving situation of multiple data blocks.

[0165] In general, the main satisfaction of Case 1, Case 2 and Case 3, any one of the cases, will actively send a reply data block reception, including file ID, packet ID, packet bitmap, SeqID +1, etc. If there are multiple groups, they will be sent together.

[0166] When the ship end updates the bitmap, it finds that some data blocks of the group are all synchronized, and it needs to do group data verification. At this time, the ship end will first start a new group for transmission, then all groups will compete for the expansion window, and finally send a verification request. The verification request includes file ID, transmission completed group ArrayID, and calculated corresponding MD5 check value, SeqID, etc. If multiple groups are synchronized, they will be checked together. Each group is checked only once.

[0167] Exemplarily, in some specific embodiments, the ship end will periodically send a heartbeat request, and the request content includes heartbeat SeqID, file ID, etc. The sending frequency SendFrequency can be self-defined and controlled, and generally it is sent once every 1s (recommended between 500ms and 1s). The main reasons for setting the heartbeat request are as follows:

[0168] 1) Determine the network state. The ship end can determine the network state through the heartbeat request reply. If the heartbeat reply is not received for several times, it means that the network quality is very poor, at which time the sending progress will be adjusted, or even stopped.

[0169] 2) Improve transmission speed. The shore end will update the bitmap information immediately after receiving the heartbeat, and the ship end will send data based on the latest bitmap. Because the heartbeat is periodic, this mechanism can well avoid the extreme situation that the ship end can never get the latest bitmap due to the loss of other data packets, and can speed up the movement of the ship end sending window and improve the transmission speed.

[0170] The shore end will process the heartbeat request after receiving it and reply the ship end with heartbeat SeqID, file ID, bitmap start ID, incremental bitmap information, etc. The ship end needs to determine the network quality based on the heartbeat reply.

[0171] In some embodiments, the method further comprises at least one of the following steps: obtaining first check information of the transmission data, calculating second check information by checking the first synchronization data of the second end in response to the transmission data; performing first check based on the first check information and the second check information; wherein, when the result of the first check is inconsistent, performing first retransmission feedback to the first end; obtaining third check information of the file to be synchronized, calculating fourth check information by checking the second synchronization data of the second end in response to the file to be synchronized; performing second check based on the third check information and the fourth check information; wherein, when the result of the second check is inconsistent, performing second retransmission feedback to the first end.

[0172] For example, in some embodiments, when the check request is received, ArrayID is calculated based on the block ID by formula (3), and then the corresponding MD5 check value is calculated. Assuming that the MD5 check value calculated by the shore end is A1, and the MD5 check value calculated by the ship end is A2.

[0173] If A1 and A2 are consistent, the check is consistent. If A1 and A2 are inconsistent, it means that the data may be tampered with, the bitmap state of the group is reset to waiting synchronization, the check is inconsistent, and the latest incremental bitmap is replied. This is one of the core points of the present application, that is, the data of the block check failure can be actively retransmitted.

[0174] The shore end will reply the contents including file ID, transmission completed group ArrayID, check result, SeqID+1, etc., and will also send the current bitmap information being transmitted.

[0175] If the check is consistent, the data synchronization of the group is successful, and the check is successful. If the check is inconsistent, the bitmap state of the group is reset to waiting synchronization, and needs to be retransmitted. Based on experience, this situation is rare.

[0176] For example, in some embodiments, based on the ship end bitmap, the ship end determines that all data are received after the data synchronization is successful. At this time, a check request is sent, and the request contents mainly include the information of the current transmission file (file name, file ID, MD5, file size, last modification time, etc.).

[0177] After receiving the check request, the shore end recalculates the MD5 of the file, and then compares it with the requested MD5. If they are consistent, it means that the file transmission is successful. If they are inconsistent, it means that part of the data packet may be tampered with. In most cases, the MD5 is consistent.

[0178] The shore end returns the MD5 check condition, mainly the information of the current transmission file (file name, file ID, MD5, file size, last modification time, etc.). After receiving the reply, the shore end records the transmission condition, marks that the file has completed synchronization, and notifies the user. If the MD5 is consistent, the user is notified that the file transmission is successful, otherwise the user is notified that the intermediate data is tampered with and needs to be re-synchronized (here, the data will not be reset and emptied, and the user needs to actively retransmit). Simply put, the data that fails the block check can be actively retransmitted, but if it reaches the final check step, the data that fails the check will not be actively retransmitted, and the user will be prompted to retransmit.

[0179] To explain the principle of the technical scheme of the present application, the overall process of the present application will be described below in conjunction with some specific embodiments. It should be easily understood that the following is an explanation of the technical principle of the present application and cannot be regarded as a limitation of the present application.

[0180] First of all, it needs to be pointed out that the existing work idea: the current data synchronization from the ship end to the shore end is divided into three stages of metadata preparation, data synchronization and final check, and the transmission feature is to send data in a fixed window, and all data is sent or re-sent in sequence, without realizing true out-of-order sending.

[0181] Disadvantages of the current mainstream scheme:

[0182] 1) Slow speed: Currently, data from the ship end to the shore end is mainly transmitted through satellites, and the satellite bandwidth is relatively low, resulting in slow data synchronization speed.

[0183] 2) Poor experience: Considering the low satellite bandwidth and the need for networking for data synchronization and ship personnel, bandwidth contention may occur, resulting in poor user internet experience.

[0184] 3) Low synchronization success rate: Currently, data synchronization is mainly based on TCP for transmission, and the data transmission integrity is theoretically guaranteed, but considering the low satellite bandwidth, data transmission failure often occurs halfway.

[0185] Disadvantages of the existing work scheme:

[0186] 1) Large bitmap storage ratio: All data is organized based on a one-level bitmap, and the array organization is single, and the bitmap information exchange efficiency is low;

[0187] 2) Data is sent in sequence: All data blocks are sent or re-sent one by one, and multiple range data blocks cannot be sent concurrently (such as simultaneous transmission from the beginning and from the end).

[0188] 3) Fixed sending window: In a particularly congested network, the fixed window reacts slowly, still causing some bandwidth waste, resulting in a decrease in data transmission speed.

[0189] In view of this, the present application provides a ship end to shore number of data out-of-order dynamic synchronization method, reference Figure 8 , the specific steps are as follows:

[0190] Step 1. Data local compression. The ship end of the file to be transmitted generally has many, mainly the test results of technical experiments, including table, text, picture and other files, and less high-definition video. These data files need to be compressed before transmission, and the present application adopts the open source LZMA2 compression algorithm, which has a very high compression rate. Compared with other compression algorithms, the compression speed will be slightly slower, but considering the satellite bandwidth, the higher compression rate is still necessary. In the data transmission management regulations on the ship, it is not recommended to transmit high-definition video. This is because the video is usually in compressed format, and even if LZMA2 is used for further compression, the file compression rate will not be too high, and the video will occupy a large amount of bandwidth and affect the transmission of other files, so the high-definition video file is usually synchronized by direct copying after the ship docks.

[0191] Under normal circumstances, there will be multiple files to be synchronized, and these files are sorted according to the last modification time, and the files will be divided into multiple groups for compression. The present application divides the group according to 100M as the benchmark, that is, the sum of the file size of each group is about 100M, if a single file exceeds 100M, then this file is a group. Then compress each group, and the compressed package name is the MD5 of all file names, so a series of compressed packages will be obtained. This grouping standard can be adjusted, but it is not recommended to exceed 200M, because the larger the compressed file, the higher the file transmission failure rate. These compressed packages are transmitted synchronously one by one, and the present application is for single compressed package data synchronization.

[0192] In most cases, the compression rate of text invention can reach about 60%, that is, the size of the compressed text invention is about 40% of the original size, and according to the 100M grouping, the single compressed package is about 40M. In actual scenarios, the compression rate can even reach 70%.

[0193] Regarding grouping, let's take an example. Suppose file A (size 80M), B (size 17M), C (size 60M), D (size 60M), E (size 70M), F (size 80M), G (170M) and other 7 files have been sorted according to the last modification time, then the grouping is as follows:

[0194] 1) A (size 80M) and B (size 17M) are a group, because A+B=97M, which is close to 100M, and the compressed package name is MD5(AB);

[0195] 2) C (size 60M) and D (size 60M) are a group, C is 60M, 40M away from 100M, but C+D = 120M, 20M more than 100M, so C and D are a group, the compressed package name is MD5(CD);

[0196] 3) E (size 70M) is a group alone, E is 70M, 30M away from 100M, but E+F = 150M, 50M more than 100M, so E is a group alone, the compressed package name is MD5(E);

[0197] 4) F (size 80M) is a group alone, the reason is the same as E;

[0198] 5) G (size 170M) is a group alone;

[0199] In summary, it is divided into 5 groups, and each group is compressed into a package using LZMA2.

[0200] Step 2. Initiate the ship end data synchronization request. The ship end sends a data synchronization request, which is forwarded to the shore end through the satellite, mainly including detailed information of the transmission data compressed package, including the file name, file size, file MD5, file creation time, last modification time, bitmap grouping and other information, which are mainly used to determine whether breakpoint resume is needed.

[0201] Step 3. Check the data synchronization situation. When the shore end receives the data synchronization request, it will check the files transmitted by the shore end, and the judgment process is mainly as follows:

[0202] 1) Check the file name, check whether the file exists on the shore end. If it does not exist, it means that the file is transmitted for the first time. If it does not exist, continue to compare the file MD5;

[0203] 2) Check the file MD5, check whether the shore end file MD5 and the target file MD5 are consistent. If they are not consistent, it means that the target file has changed, and it needs to be retransmitted. If they are consistent, continue to compare the file size.

[0204] 3) Check the bitmap information and file size of the present invention, if they are consistent, it means that the file has been transmitted before, and breakpoint resume can be selected. If they are not consistent, it means that the target file has changed, and it needs to be retransmitted. This step is necessary because the file is stored in the cache area before the transmission is successful, and the cache may be tampered or cleared.

[0205] 4) Check the bitmap information of all groups, if all data packages have been received, it means that the data synchronization is successful, otherwise it needs to be transmitted from the beginning or breakpoint resume. If the data has been transmitted successfully, check the final verification flag of the shore end, if it has been completed, reply to the ship end that the synchronization is successful, otherwise reply that the final verification is needed.

[0206] Where the bitmap information is used to mark the shore end receiving file case, the invention uses two-level bitmap. Simply put, the file to be transmitted is divided into groups according to SubSize, and each group calculates its own bitmap. Referring to the following formula, FileSize is the file size, SubSize is the grouping size, ArraySize calculated by formula (1) is the number of groups (the calculation result is rounded up), PacketSize is the data block size, and BitMapSize calculated by formula (2) is the bitmap size of each group.

[0207]

[0208] So the bitmap size of each group is bytes, and each position of the bitmap is 0 indicating no data received and 1 indicating data received. For each block ID, its corresponding group ID can be calculated by formula (3), and in the corresponding group, its position in the bitmap can be calculated by formula (4):

[0209]

[0210] ArrayIndex = ID % ArraySize (4)

[0211] Suppose the compressed file is FileSize 50.5M, and each group SubSize is 1M, then ArraySize is 51. Each data packet is transmitted using UDP protocol, and each data block PacketSize is 1K, so the bitmap BitMapSize of each group is 1024. There is a special case here, there are 51 groups in total, and the BitMapSize of group 0 to group 49 is 1024, and the BitMapSize of group 50 is That is, the BitMapSize of the last group is dynamically calculated according to the actual situation.

[0212] Suppose the data block ID is 5, then its group ArrayID is The bitmap position in group 0 is 5%1024 = 5, that is, the bitmap position of data block ID 5 is position 5 in group 0.

[0213] Suppose the data block ID is 2299, then its group ArrayID is The bitmap position in group 2 is 2299%1024 = 251, that is, the bitmap position of data block ID 2299 is position 251 in group 2.

[0214] Compared with the primary bitmap, the biggest change of the secondary bitmap is cutting into multiple sub-bitmaps, which is to facilitate multiple group data concurrent transmission, and this feature is one of the core points of the application and cannot be achieved by previous work.

[0215] Step 4. Shore end data synchronization condition reply. After the check is completed, the monitoring conditions are directly fed back to the ship end, mainly the file information (file name, MD5, file bitmap, file size, last modification time, transmission progress, etc.) existing in the shore end. Note that the bitmap here is a full bitmap, i.e. bitmap information of each group. If the data of a group has been transmitted, the transmission of the bitmap is no longer required, which is to reduce the transmission bandwidth.

[0216] Step 5. Dynamic adjustment of sending window. Each group has its own sending window, i.e. different groups can be concurrent, i.e. multiple data transmission at the same time, which is one of the core points of the application. Assuming that the maximum number of concurrent groups is ParallelNum (which can be configured, at least 1, usually configured as 3-5), i.e. at most three groups are concurrent. The sending window of each group is dynamically calculated and adjusted, and the adjustment mode of different groups is consistent, so the adjustment mode of the window is described from the perspective of a group.

[0217] The window size WindowSize starts from 1, and after receiving the reply from the shore end each time, the window is doubled (reference formula 5) or halved (reference formula 8). When the window exceeds the middle critical value MidSize, the window expansion operation is increased by 1 each time (reference formula 6), instead of doubling, and the window is reduced by 1 each time (reference formula 9), instead of halving. When the window exceeds the maximum critical value FinSize, the window will not grow, i.e. the maximum critical value (reference formula 7).

[0218] WindowSize = WindowSize * 2, WindowSize < MidSize (5)

[0219] WindowSize = WindowSize + 1, FinSize > WindowSize ≥ MidSize (6)

[0220] WindowSize = WindowSize, WindowSize ≥ FinSize (7)

[0221]

[0222] WindowSize = WindowSize - 1, WindowSize ≥ MidSize (9)

[0223] The intermediate threshold value MidSize and the maximum threshold value FinSize can be customized, and are generally determined based on network communication bandwidth and practical experience. In scenarios based on ship-to-shore data synchronization, through extensive testing, MidSize is typically 8 and FinSize is typically 12.

[0224] For a group, the operation of expanding or shrinking the window is mainly based on the following rules:

[0225] Case 1: When the data packet is received in chunks from the shore, if the Seq sequence numbers are consecutive, it indicates that the data was received successfully very quickly, and the window expands. Here, consecutive Seq sequence numbers mean that if the ship sends Seq1 and the shore replies with Seq1+1, it can be considered consecutive.

[0226] Case 2: When the data packet is received in chunks from the shore, if the Seq sequence number is not consecutive, but the Seq difference does not exceed MaxSeqLen (which can be customized and is set to 2 by default), it indicates that the data reception is normal and the window remains unchanged.

[0227] Case 3: When the data packet is received in chunks from the shore, if the Seq sequence number is not consecutive, but the Seq difference exceeds MaxSeqLen, it indicates that the data reception is somewhat blocked, and the window is reduced.

[0228] Case 4: When the packet receives a heartbeat response from the shore, if the Seq sequence number is consecutive, the window remains unchanged. Normally, the heartbeat frequency is once per second, which is a bit slow to reflect network latency, so the window is kept constant here.

[0229] Case 5: When a heartbeat response is received from the shore, if the sequence number is discontinuous, the window size should be reduced. Discontinuous heartbeat sequences indicate severe network congestion, necessitating window size reduction.

[0230] Case 6: When multiple transmission packets exist (i.e., ArraySize ≥ 2), and a new packet is started to participate in transmission after one packet has been transmitted. In this case, all packets compete for the window expansion opportunity, and the number of window expansion opportunities does not exceed half the number of packets. First come, first served; that is, the first group to request window expansion will have its window expanded, while the windows of other groups remain unchanged. If all group windows were expanded, it could cause momentary network congestion, so window expansion here is a competitive process.

[0231] Case7: When the bitmap is updated, if a certain packet is suspected to be lost, and the number does not exceed MaxLostNum (which can be configured by default, 3), the window remains unchanged.

[0232] Case8: When the bitmap is updated, if a certain packet is suspected to be lost, and the number exceeds MaxLostNum, the window is reduced.

[0233] Case9: If the above several situations are encountered at the same time, if they are all window expansion operations or expansion operations and remain unchanged, the window is expanded once, if they are all window reduction operations or reduction operations and remain unchanged, the window is reduced once, and otherwise the window remains unchanged.

[0234] In general, the sending window is dynamically adjusted based on multiple conditions. When receiving data receiving replies, heartbeat replies, updating bitmaps, etc., the window is dynamically adjusted. Based on the dynamic window adjustment strategy, flexible data transmission control is achieved, thereby improving the transmission speed.

[0235] Step 6. Out-of-order sending of data blocks. For single-packet data transmission, if there is still part of the data that has not been synchronized, prepare to send the data blocks out of order. Referring to Figure 5 , the state of the data is divided into three states: synchronization, waiting for synchronization, and synchronization completed. It can be seen that packet 01 has been synchronized and completed, packets 02-06 are in synchronization, and for packet 02 data block 03 suspected to be lost, it is currently being retransmitted.

[0236] The window of each packet is dynamically calculated. If the number of data blocks in the synchronization state SyningNum is less than the current sending window size WindowSize (i.e. SyningNum < WindowSize), the data will be selected to be sent or retransmitted.

[0237] If the number of data blocks in the synchronization state SyningNum is not less than the current sending window size WindowSize (i.e. SyningNum >= WindowSize), the current state remains unchanged. When a certain data is suspected to be lost, the data state is modified to be synchronized, at which time the synchronization state data packet is reduced, SyningNum = SyningNum-1. This operation is continuously executed until SyningNum == WindowSize.

[0238] How to determine that a certain data packet is suspected to be lost? If the data block processing state is in synchronization, and the SeqID received by the bitmap update exceeds the SeqID of the data block sent, the data block is suspected to be lost.

[0239] Unlike the existing method, the present application regards the retransmission data packet and other data packets as the same, and sends data as long as there is a seat in the sending window. If the sending window is full, it will stop sending, at which time the data suspected to be lost will not be retransmitted until there is a seat in the window.

[0240] Step 7. The data blocks are received out of order and stored in order. The shore end will receive multiple UDP data packets, including file ID, block ID, data block, SeqID, etc. According to the file ID, it is determined which file the data belongs to, and according to the block ID, the block position is determined. Based on the block ID, ArrayID is calculated by formula (3), and ArrayIndex is calculated by formula (4), i.e. the specific position in the group is determined.

[0241] Considering network factors and breakpoint retransmission, the data packets received by the shore end may not arrive in order, but the shore end will store them in order according to the block ID, and the data that has not been received temporarily belongs to the "breakpoint" data. At the same time, the shore end may receive the same file ID and block ID data packet multiple times, and if it has been saved, the duplicate data packet is discarded directly.

[0242] Reference Figure 6 Data sending process, under normal circumstances, the repeated sending of data by the ship end and the receiving of data by the shore end can easily affect the transmission efficiency, so the ship end will dynamically adjust the sending window and adjust the sending rhythm, and the shore end will regularly check the data and reply to the ship end. When the data loss is clear, the ship end retransmits the data according to the sending window to realize breakpoint resume.

[0243] Step 8. Regularly reply to data block receiving situation. The shore end will receive a large number of data packets and store them in order, and the shore end will immediately reply to the data block receiving situation when the following conditions are met:

[0244] Case 1: Reply to data block receiving situation every time data is received.

[0245] Case 2: When the block check request is received, immediately reply to the data block receiving situation.

[0246] Case 3: When the heartbeat request is received, immediately reply to the data block receiving situation.

[0247] It should be noted that in step 6, multiple groups send data blocks concurrently, and in most cases, the shore end will receive multiple packets at the same time, and will process the received data first, and then reply to the received bitmap information of the relevant group. Through most experiments, it is often found that one reply packet replies to the receiving of multiple data blocks.

[0248] In general, the main satisfaction of Case 1, Case 2 and Case 3, any one of the cases, will actively send a reply data block reception, including file ID, packet ID, packet bitmap, SeqID+1 and other content. If there are multiple groups, they will be sent together.

[0249] Step 9. Periodically send block check request. When the ship end updates the bitmap, it finds that some data blocks of the packet are all synchronized, and it needs to do packet data check. At this time, the ship end will first start a new packet for transmission, then all packets will compete for the expansion window, and finally send the check request. The check request includes file ID, transmission completed packet ArrayID, and calculated MD5 check value, SeqID and other contents. If multiple groups are synchronized, block check will be done together. Each group is checked only once.

[0250] Step 10. Check the received data. When the check request is received, the ArrayID is calculated based on the block ID by formula (3), and then the corresponding MD5 check value is calculated. Assuming that the MD5 check value calculated by the shore end is A1, and the MD5 check value calculated by the ship end is A2.

[0251] If A1 and A2 are consistent, reply that the check is consistent. If A1 and A2 are not consistent, it means that the data may be tampered with, then reset the bitmap state of the group to waiting synchronization, reply that the check is inconsistent, and reply the latest incremental bitmap. This is one of the core points of the present application, that is, the data of block check failure can be actively retransmitted.

[0252] The shore end will reply including file ID, transmission completed packet ArrayID, check result, SeqID+1 and other contents, and also send the current bitmap information being transmitted.

[0253] Step 11. Reply data check situation and selective retransmission. If the check is consistent, the packet data synchronization is successful, and the check is successful. If the check is inconsistent, reset the bitmap state of the group to waiting synchronization, and need to be retransmitted. Based on experience, this situation is rarely seen.

[0254] Step 12. Send heartbeat request. The ship end will periodically send a heartbeat request, and the request content includes heartbeat SeqID, file ID and other information. Send a heartbeat every time. The sending frequency SendFrequency can be controlled by the user, and generally it is sent once every 1s (recommended between 500ms and 1s). The main reasons for setting the heartbeat request are as follows:

[0255] 1) Determine network status. The ship end can determine the network status through the heartbeat request reply. If the heartbeat reply is not received for several times, it means that the network quality is very poor, at which time the sending progress will be adjusted, or even stopped.

[0256] 2) Improve transmission speed. The shore side updates the bitmap information immediately after receiving the heartbeat, and the ship side sends data based on the latest bitmap. Because the heartbeat is periodic, this mechanism avoids the extreme case of the ship side never being able to obtain the latest bitmap due to other packet loss, speeds up the movement of the ship side sending window, and improves transmission speed.

[0257] Step 13. Heartbeat reply. After receiving the heartbeat request, the shore side processes it and replies with the heartbeat SeqID, file ID, bitmap start ID, and incremental bitmap information to the ship side. The ship side needs to make a network quality determination based on the heartbeat reply. How to determine it is described in step 5.

[0258] Step 14. Data synchronization success, send verification request. Based on the ship side bitmap, the ship side determines that all data has been received, indicating that data synchronization is successful. At this time, a verification request is sent, and the request content mainly includes the information of the current transmission file (file name, file ID, MD5, file size, last modification time, etc.).

[0259] Step 15. Data local verification. After receiving the verification request, the shore side recalculates the MD5 of the file and compares it with the requested MD5. If they are consistent, it indicates that the file transmission is successful. If they are not consistent, it indicates that part of the data packet may have been tampered with. In most cases, the MD5s are consistent.

[0260] Step 16. Reply to data verification situation. The shore side replies with the MD5 verification situation, mainly including the information of the current transmission file (file name, file ID, MD5, file size, last modification time, etc.). After receiving the reply, the shore side records the transmission situation, marks that the file has completed synchronization, and notifies the user. If the MD5s are consistent, the user is notified that the file transmission is successful. Otherwise, the user is notified that the intermediate data has been tampered with and needs to be re-synchronized (here, the data will not be reset and emptied, and the user needs to actively retransmit). In short, the data that fails the block verification can be actively retransmitted, but if it reaches the final verification step, the data that fails the verification will not be actively retransmitted, and the user will be prompted to retransmit.

[0261] When steps 14 to 16 are completed, the file is marked as completed synchronization, and the next file will be transmitted. There is an extreme case that needs to be explained. If the file has just been successfully transmitted, and the network suddenly disconnects, the ship side cannot receive the data verification reply in time. At this time, the file is still in the synchronization state, and after the network is restored, the ship side will resend the verification request until it receives the verification reply. The transmission process of the file is considered to be truly completed. In addition, it should be noted that the SeqID mentioned in the invention is a global self-incrementing variable. After each use, SeqID = SeqID + 1. SeqID is mainly used to correspond to the request packet and the reply packet.

[0262] In summary, the entire transmission is divided into three stages:

[0263] 1) Preparation stage, including steps 1 to 4, which mainly clarifies the information of the shore transmission file, synchronizes the latest bitmap, and belongs to the data preparation stage before transmission;

[0264] 2) Synchronization stage, including steps 5 to 13, which mainly synchronizes data, is responsible for data synchronization and bitmap synchronization, dynamically adjusts the sending rhythm through heartbeat and block verification mechanism, and improves the efficiency of file transmission.

[0265] 3) Verification stage, including steps 14 to 16, which mainly performs the final data verification.

[0266] Compared with the prior art, the present application at least includes the following beneficial effects:

[0267] 1) Introducing a two-level bitmap to control the data sending process, optimizing the data organization structure, and facilitating concurrent sending of out-of-order data

[0268] 2) Dynamically adjusting the sending window, fully utilizing the idle bandwidth, reducing the data retransmission bandwidth, and improving the transmission speed.

[0269] 3) Regularly checking intermediate data, supporting breakpoint resume, and ensuring data integrity from the start of data download to the completion of the whole process.

[0270] On the other hand, as shown in Figure 9 The embodiment of the present application provides a ship-shore narrowband network data dynamic synchronization device 900, which can include:

[0271] The first module 901 is used for acquiring bitmap information of the first end and the second end; the bitmap information includes bitmap positions and synchronization states of all data blocks under each data packet in the file to be synchronized;

[0272] The second module 902 is used for adjusting the sending window of the data packet according to the continuous state of the interaction information between the first end and the second end;

[0273] The interaction information includes transmission information and feedback information; the transmission information includes historical transmission data sent by the first end to the second end and a heartbeat request sent periodically; the feedback information includes historical receiving feedback in response to the historical transmission data and a heartbeat reply in response to the heartbeat request;

[0274] The third module 903 is used for determining the transmission data of the data packet based on the bitmap information through the sending window;

[0275] The fourth module 904 is used for concurrently transmitting the transmission data of each data packet of the first end to the second end;

[0276] The fifth module 905 is configured to acquire receiving feedback of the second end in response to the transmission data, and update the bitmap information according to the receiving feedback;

[0277] The transmission data is merged into historical transmission data, and the receiving feedback is merged into historical receiving feedback.

[0278] The sixth module 906 is configured to return to execute the second module until the data synchronization of the file to be synchronized is completed.

[0279] In some embodiments, the apparatus can further include:

[0280] The seventh module is configured to split the file to be synchronized into a plurality of data blocks based on a preset transmission protocol, and sequentially mark a block ID of each data block.

[0281] The eighth module is configured to acquire corresponding data blocks from the file to be synchronized in a direction from small to large of the block ID based on a preset grouping size to construct data groups, and sequentially mark a group ID of each data group.

[0282] The ninth module is configured to perform a remainder operation on the block ID and the preset grouping size to obtain a grouping position of each data block in the corresponding data group.

[0283] The tenth module is configured to determine a bitmap position of each data block based on the group ID and the grouping position.

[0284] In some embodiments, the apparatus can further include:

[0285] The eleventh module is configured to reply to the first end about the receiving situation of the data blocks periodically by the second end in response to receiving information.

[0286] The receiving information includes a block check request and a heartbeat request sent periodically by the first end.

[0287] The twelfth module is configured to update the bitmap information again based on the receiving situation of the data blocks.

[0288] In some embodiments, the apparatus can further include at least one of the following:

[0289] The thirteenth module is configured to acquire first check information of the transmission data, check and calculate second check information of the first synchronization data of the second end in response to the transmission data, and perform first check based on the first check information and the second check information.

[0290] When the result of the first check is inconsistent, the first retransmission feedback is sent to the first end.

[0291] The fourteenth module is used to obtain the third verification information of the file to be synchronized, to verify and calculate the second synchronization data of the second end in response to the file to be synchronized to obtain the fourth verification information, and to perform the second verification based on the third and fourth verification information.

[0292] When the result of the second verification is inconsistent, a second retransmission feedback is sent to the first end.

[0293] The content of the method embodiments of the present invention is applicable to the device embodiments. The specific functions implemented by the device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above methods.

[0294] On the other hand, embodiments of the present invention also provide an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method for predicting the bottom boundary of the hydrate stability domain. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0295] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0296] like Figure 10 As shown, Figure 10 The hardware structure of an electronic device 1000 according to another embodiment is illustrated. The electronic device 1000 includes:

[0297] The processor 1001 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present invention.

[0298] The memory 1002 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1002 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1002 and is called and executed by the processor 1001 to execute the network node population optimization method of the embodiments of this invention.

[0299] The input / output interface 1003 is configured to realize information input and output.

[0300] The communication interface 1004 is configured to realize the communication interaction between the device and other devices, and the communication can be realized through a wired manner (for example, a USB, a network cable and the like) or a wireless manner (for example, a mobile network, WIFI, Bluetooth and the like).

[0301] The bus 1005 is configured to transmit information between various components (for example, the processor 1001, the memory 1002, the input / output interface 1003 and the communication interface 1004) of the device.

[0302] The processor 1001, the memory 1002, the input / output interface 1003 and the communication interface 1004 are connected to each other through the bus 1005 to realize the communication connection between the device.

[0303] The electronic device embodiments described above are only schematic, and the units described as separate components can or can not be physically separate, that is, can be located in one place or distributed on multiple network units. According to actual needs, part or all of the modules can be selected to realize the purposes of the embodiments.

[0304] The contents of the method embodiments of the present application are applicable to the electronic device embodiments, the functions realized by the electronic device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved by the electronic device embodiments are also the same as those achieved by the above method.

[0305] Another aspect of the embodiments of the present application further provides a computer readable storage medium, the storage medium stores a program, and the program is executed by a processor to realize the above method.

[0306] It should be noted that the computer readable medium shown in the embodiments of the present application can be a computer readable signal medium or a computer readable storage medium or any combination of the two. The computer readable storage medium may, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or component, or any combination of the above. More specific examples of computer readable storage media can include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (Compact Disc Read-Only Memory, CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, the computer readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or component. In the present application, the computer readable signal medium can include a data signal carried in a baseband or as a part of a carrier wave, which carries computer readable program code. Such a propagated data signal can take many forms, including but not limited to electromagnetic signals, optical signals or any suitable combination thereof. The computer readable signal medium can also be any computer readable medium other than the computer readable storage medium, which can send, propagate or transmit a program for use by or in conjunction with an instruction execution system, device or component. The program code contained on the computer readable medium can be transmitted by any suitable medium, including but not limited to wireless, wired or the like, or any suitable combination thereof.

[0307] The contents of the method embodiments of the present application are applicable to the computer readable storage medium embodiments of the present application. The computer readable storage medium embodiments specifically implement the same functions as the above-mentioned method embodiments, and achieve the same beneficial effects as the above-mentioned methods.

[0308] The embodiments of the present application also disclose a computer program product or computer program, which comprises computer instructions stored in a computer readable storage medium. The processor of the computer device can read the computer instructions from the computer readable storage medium, and the processor executes the computer instructions to make the computer device execute the above method.

[0309] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0310] It should be noted that although several modules for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0311] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of the present invention can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, portable hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of the present invention.

[0312] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this invention are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented in this invention. Alternative embodiments are contemplated, in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0313] Furthermore, although the present application is described in the context of functional modules, it is to be understood that one or more of the functions and / or features of'can be integrated in a single physical device and / or software module, or one or more functions and / or features can be implemented in separate physical devices or software modules. It will also be understood that detailed discussion of the actual implementation of each module is unnecessary to an understanding of the present application. Rather, the actual implementation of the modules, in combination with their attributes, functions, and internal relationships, are to be understood within the context of the devices disclosed in the present application. Thus, those skilled in the art with access to the teachings presented herein will be able to devise variations of the application without the aid of experimentation. It is also to be understood that the particular conceptualization disclosed is illustrative only and not restrictive of the application, the scope of which is to be determined by the appended claims and equivalents thereof.

[0314] If the functions are implemented in software, the functions can be stored in or implemented as one or more computer program products, which can be incorporated into a computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor- containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this specification, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

[0315] The logic and / or steps represented in the flow diagrams and / or described herein, for example, can be embodied in non-transitory computer-readable media, which can be executed by an instruction execution system, apparatus, or device such as a computer-based system, processor- containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this specification, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

[0316] More specific examples (a non-exhaustive list) of the computer-readable medium include the following: an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, and a portable compact disc read-only memory (CDROM). Additionally, the computer-readable medium can also be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, for example, via optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.

[0317] It should be understood that aspects of the application can be implemented in hardware, software, firmware or combinations thereof. In the embodiments described above, various steps or methods can be implemented, for example, by software or firmware stored in memory and executed by a suitable instruction execution device. If implemented in hardware, for example, in another embodiment, any of the following techniques can be used in whole or in part: discrete logic circuitry having logic gates for implementing logic functions upon data signals, application specific integrated circuits having appropriate combinational logic gates, programmable gate arrays (PGA), field programmable gate arrays (FPGA), and so forth, as well as or instead.

[0318] In the description of the specification, the description of the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" and the like means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Also, the specific features, structures, materials or characteristics described can be combined in any appropriate manner in one or more embodiments or examples.

[0319] Although embodiments of the present application have been shown and described, it would be recognized by those of ordinary skill in the art that various changes, modifications, alternatives, and variations can be made to the embodiments without departing from the principles and spirit of the application, the scope of which is defined by the claims and their equivalents.

[0320] The above is a specific description of the preferred embodiments of the present application, but the present application is not limited to the embodiments, and those skilled in the art can make various equivalent modifications or replacements without departing from the spirit of the present application, and these equivalent modifications or replacements are all included in the scope defined by the claims of the present application.

Claims

1. A method for dynamic data synchronization in a ship-to-shore narrowband network, characterized in that, Includes the following steps: Obtain bitmap information from the first and second ends; the bitmap information includes the bitmap positions and synchronization status of all data blocks under each data group in the file to be synchronized; The sending window of the data packet is adjusted according to the continuous state of the interaction information between the first end and the second end; The interaction information includes transmission information and feedback information; the transmission information includes historical transmission data sent from the first end to the second end and periodically sent heartbeat requests; the feedback information includes historical reception feedback in response to the historical transmission data and heartbeat responses in response to the heartbeat requests. Based on the bitmap information, the transmission data of the data packet is determined through the sending window; The data of each data group at the first end is transmitted concurrently to the second end; Obtain the second end's response to the transmitted data and update the bitmap information based on the response. The transmitted data is merged into the historical transmitted data, and the received feedback is merged into the historical received feedback; Return to the step of adjusting the sending window of the data packet according to the continuous state of the interaction information between the first end and the second end, until the file to be synchronized completes data synchronization.

2. The method for dynamic synchronization of ship-to-shore narrowband network data according to claim 1, characterized in that, The method further includes the following steps: The file to be synchronized is divided into several data blocks based on a preset transmission protocol, and then the block ID of each data block is sequentially marked. Based on the preset group size, the corresponding data blocks are obtained from the file to be synchronized in ascending order of the block ID to construct the data group, and then the group ID of each data group is sequentially marked. The remainder of the block ID and the preset group size is used to obtain the group position of each data block in its corresponding data group. The bitmap position of each data block is determined based on the group ID and the group position.

3. The method for dynamic synchronization of ship-to-shore narrowband network data according to claim 1, characterized in that, The continuous state includes continuity and sequence number difference, and the continuity includes continuity or discontinuity; adjusting the sending window of the data packet according to the continuous state of the interaction information between the first end and the second end includes the following steps: The latest data sent by the first end is obtained from the historical transmission data as the target transmission data, and the latest response data from the second end is obtained from the historical reception feedback as the target reception feedback; The latest heartbeat request sent by the first end is taken as the target heartbeat request, and the latest heartbeat response from the second end is taken as the target heartbeat response; A first continuous state is determined based on the target transmitted data and the Seq sequence number carried in the target received feedback; the first continuous state includes a first continuity and a first sequence number difference. A second continuous state is determined based on the heartbeat request and the Seq sequence number carried in the heartbeat response; the second continuous state includes the second continuity and the difference between the second sequence number. The window size of the sending window is adjusted based on either the first continuous state or the second continuous state.

4. The method for dynamic synchronization of ship-to-shore narrowband network data according to claim 3, characterized in that, Adjusting the window size of the sending window based on the first continuous state or the second continuous state includes at least one of the following steps: If the first continuity is continuous, the window size is expanded; otherwise, the first sequence number difference is determined; if the first sequence number difference is greater than a preset difference threshold, the window size is shrunk; otherwise, the window size is not adjusted. If the second continuity is continuous, the window size is not adjusted; otherwise, the window size is reduced. The expansion process includes doubling expansion, step expansion, and no expansion; the shrinking process includes halving shrinking and gradual shrinking; the expansion and shrinking methods are determined based on the window size before the sending window is adjusted.

5. The method for dynamic synchronization of ship-to-shore narrowband network data according to claim 1, characterized in that, The received feedback includes the bitmap position of the data block that has been received; updating the bitmap information according to the received feedback includes the following steps: Based on the bitmap position, the data block included in the transmitted data is compared with the data block that has been received in the received feedback to determine the target data block that has completed synchronization; Update the synchronization status of the target data block to complete synchronization.

6. The method for dynamic synchronization of ship-to-shore narrowband network data according to claim 1, characterized in that, The method further includes the following steps: The second end responds to the received information and periodically replies to the first end with the data block reception status; The received information includes the block verification request and the heartbeat request periodically sent by the first end; The bitmap information is updated a second time based on the data block reception status.

7. The method for dynamic synchronization of ship-to-shore narrowband network data according to claim 1, characterized in that, The method further includes at least one of the following steps: First verification information of the transmitted data is obtained; second verification information is obtained by verifying and calculating the first synchronization data of the second end in response to the transmission data; first verification is performed based on the first verification information and the second verification information. When the result of the first verification is inconsistent, a first retransmission feedback is sent to the first end. Obtain the third verification information of the file to be synchronized; perform verification calculation on the second synchronization data of the second end in response to the completion of synchronization of the file to be synchronized to obtain the fourth verification information; perform the second verification based on the third verification information and the fourth verification information; If the result of the second verification is inconsistent, a second retransmission feedback is sent to the first end.

8. A ship-to-shore narrowband network data dynamic synchronization device, characterized in that, include: The first module is used to obtain bitmap information from the first and second ends; The bitmap information includes the bitmap positions and synchronization status of all data blocks under each data group in the file to be synchronized; The second module is used to adjust the sending window of the data packet according to the continuous state of the interaction information between the first end and the second end; The interaction information includes transmission information and feedback information; the transmission information includes historical transmission data sent from the first end to the second end and periodically sent heartbeat requests; the feedback information includes historical reception feedback in response to the historical transmission data and heartbeat responses in response to the heartbeat requests. The third module is used to determine the transmission data of the data packet based on the bitmap information through the sending window; The fourth module is used to concurrently transmit the transmission data of each data group from the first end to the second end; The fifth module is used to obtain the second end's response to the transmitted data and update the bitmap information according to the response. The transmitted data is merged into the historical transmitted data, and the received feedback is merged into the historical received feedback; The sixth module is used to return to the execution of the second module until the file to be synchronized has completed data synchronization.

9. An electronic device, characterized in that, Including the processor and memory; The memory is used to store programs; The processor executes the program to implement the method as described in any one of claims 1 to 7.

10. A computer storage medium storing a processor-executable program, characterized in that, The processor-executable program, when executed by the processor, is used to implement the method as described in any one of claims 1 to 7.

Images