Ship-shore narrow-band network data dynamic synchronization method, device, equipment and medium

Abstract

The invention discloses a ship-shore narrow-band network data dynamic synchronization method and device, equipment and a medium. The method comprises the following steps: acquiring bitmap information of a first end and a second end; adjusting a sending window of the data packet according to the continuous state of the interaction information between the first end and the second end; determining transmission data of the data packet through the transmission window based on the bitmap information; concurrently transmitting the transmission data of each data packet of the first end to the second end; 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; wherein the transmission data is merged into historical transmission data, and the receiving feedback is merged into historical receiving feedback; and returning 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 the to-be-synchronized file completes data synchronization. The ship-shore narrow-band network data dynamic synchronization method can efficiently realize ship-shore narrow-band network data dynamic synchronization, and can be widely applied to the technical field of data processing.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a method, device, equipment and medium for dynamic synchronization of ship-shore narrowband network data. Background Art

[0002] With the growing demand for data exchange between ships and land, data synchronization technology from ship to shore has become a key link to ensure real-time information transmission and business continuity. Currently, TCP (Transmission Control Protocol) is widely used as the basic communication mechanism for data synchronization in this field. This choice 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 and the shore is achieved.

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

[0004] However, although the existing technology has met the basic needs of ship-to-shore data synchronization to a certain extent, its limitations are gradually emerging when facing large-scale data synchronization tasks or complex and changeable network environments. Although the fixed window sending strategy has improved the transmission efficiency to a certain extent, it may cause data transmission delays or interruptions when the network fluctuates greatly, affecting the real-time and reliability of synchronization. In addition, with the continuous increase in data volume, how to further optimize the transmission strategy, improve resource utilization, and ensure the integrity and accuracy of data has become a problem that needs to be solved by current technology. Summary of the invention

[0005] The present invention aims to solve the problem of related technical limitations at least to a certain extent. To this end, the present invention proposes a method, device, equipment and medium for dynamic synchronization of ship-shore narrowband network data, which can efficiently perform dynamic synchronization of ship-shore narrowband network data.

[0006] On the one hand, an embodiment of the present invention provides a method for dynamic synchronization of ship-shore narrowband network data, comprising:

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

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

[0009] The interactive information includes transmission information and feedback information; the transmission information includes historical transmission data sent by the first end to the second end and heartbeat requests sent regularly; the feedback information includes historical reception feedback in response to historical transmission data and heartbeat replies in response to heartbeat requests;

[0010] Based on the bitmap information, determine the transmission data of the data packet through the sending window;

[0011] Concurrently transmitting the transmission data of each data packet of the first end to the second end;

[0012] Obtaining reception feedback from the second end in response to the transmission data, and updating the bitmap information according to the reception feedback;

[0013] Among them, the transmission data is merged into the historical transmission data, and the reception feedback is merged into the historical reception feedback;

[0014] 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 data synchronization of the file to be synchronized is completed.

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

[0016] Split the file to be synchronized into several data blocks based on the preset transmission protocol, and then sequentially mark the block ID of each data block;

[0017] Based on the preset group size, the corresponding data blocks are obtained from the to-be-synchronized file in order from the small to the large block ID to construct data groups, and then the group ID of each data group is marked in sequence;

[0018] Perform a remainder operation on the block ID and the preset group size to obtain the group position of each data block in its corresponding data group;

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

[0020] Optionally, the continuity 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 continuity state of the interactive information between the first end and the second end includes the following steps:

[0021] 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 of the second end is obtained from the historical reception feedback as the target reception feedback;

[0022] The most recent heartbeat request sent by the first end is used as the target heartbeat request, and the most recent heartbeat reply of the second end is used as the target heartbeat reply;

[0023] Determine a first continuous state according to the target transmission data and the Seq sequence number carried in the target reception feedback; the first continuous state includes a first continuity and a first sequence number difference;

[0024] Determine a second continuous state according to the heartbeat request and the Seq sequence number carried by the heartbeat reply; the second continuous state includes the second continuity and the difference between the second sequence number;

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

[0026] Optionally, 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:

[0027] When the first continuity is continuous, the window size is expanded; otherwise, the first sequence number difference is determined; when the first sequence number difference is greater than a preset difference threshold, 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] Among them, the expansion processing includes doubling expansion, step expansion and no expansion, and the reduction processing includes halving reduction and step reduction; the expansion processing and reduction processing methods are determined based on the window size before the sending window is adjusted.

[0030] Optionally, receiving feedback includes completing a bitmap position of the received data block; and updating the bitmap information according to the received feedback includes the following steps:

[0031] Based on the bitmap position, compare the data blocks included in the transmission data with the data blocks that have been received and included in the reception feedback, and determine the target data blocks that have completed synchronization;

[0032] Update the synchronization status of the target data block to complete synchronization.

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

[0034] In response to the received information, the second end periodically replies to the first end about the reception status of the data blocks;

[0035] The received information includes a block verification request and a heartbeat request periodically sent by the first end;

[0036] The bitmap information is updated twice based on the data block reception situation.

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

[0038] Acquire first verification information of the transmission data, verify and calculate first synchronization data of the second end in response to the transmission data to obtain second verification information; perform a first verification based on the first verification information and the second verification information;

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

[0040] Acquire third verification information of the file to be synchronized, verify and calculate the second synchronization data of the second end in response to the completion of synchronization of the file to be synchronized to obtain fourth verification information; perform a second verification based on the third verification information and the fourth verification information;

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

[0042] On the other hand, an embodiment of the present invention provides a ship-shore narrowband network data dynamic synchronization device, comprising:

[0043] The first module is used to obtain bitmap information of the first end and the second end; the bitmap information includes the bitmap position and synchronization status of all data blocks under each data group in the file to be synchronized;

[0044] A second module, configured to adjust a sending window of data packets according to a continuous state of interaction information between the first end and the second end;

[0045] The interactive information includes transmission information and feedback information; the transmission information includes historical transmission data sent by the first end to the second end and heartbeat requests sent regularly; the feedback information includes historical reception feedback in response to historical transmission data and heartbeat replies in response to heartbeat requests;

[0046] A third module is used to determine the transmission data of the data packet through the sending window based on the bitmap information;

[0047] A fourth module is used to concurrently transmit the transmission data of each data packet of the first end to the second end;

[0048] A fifth module is used to obtain reception feedback from the second end in response to the transmission data, and update the bitmap information according to the reception feedback;

[0049] Among them, the transmission data is merged into the historical transmission data, and the reception feedback is merged into the historical reception feedback;

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

[0051] Optionally, the device further comprises:

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

[0053] An eighth module is used to obtain corresponding data blocks from the to-be-synchronized file in order from small to large block IDs based on a preset group size to construct data groups, and then sequentially mark the group ID of each data group;

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

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

[0056] Optionally, the device further comprises:

[0057] An eleventh module is used to periodically reply to the first end about the data block reception status in response to the received information through the second end;

[0058] The received information includes a block verification request and a heartbeat request periodically sent by the first end;

[0059] The twelfth module is used to perform secondary update on the bitmap information based on the data block reception status.

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

[0061] A thirteenth module is used to obtain first verification information of the transmission data, verify and calculate the first synchronization data of the second end in response to the transmission data to complete synchronization to obtain second verification information; and perform a first verification based on the first verification information and the second verification information;

[0062] When the result of the first check is inconsistent, a first retransmission feedback is performed to the first end;

[0063] A fourteenth module is used to obtain third verification information of the file to be synchronized, verify and calculate the second synchronization data of the second end in response to the completion of synchronization of the file to be synchronized to obtain fourth verification information; and perform a second verification based on the third verification information and the fourth verification information;

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

[0065] On the other hand, an embodiment of the present invention provides an electronic device, including: a processor and a memory; the memory is used to store programs; the processor executes the program to implement the above-mentioned ship-shore narrowband network data dynamic synchronization method.

[0066] On the other hand, an embodiment of the present invention provides a computer storage medium, in which a program executable by a processor is stored. When the program executable by the processor is executed by the processor, it is used to implement the above-mentioned method for dynamic synchronization of ship-shore narrowband network data.

[0067] The embodiment of the present invention obtains the bitmap information of the first end and the second end; the bitmap information includes the bitmap position and synchronization status of all data blocks under each data group in the file to be synchronized; the sending window of the data group is adjusted according to the continuous state of the interactive information between the first end and the second end; wherein the interactive information includes transmission information and feedback information; the transmission information includes the historical transmission data sent by the first end to the second end and the heartbeat request sent regularly; the feedback information includes the historical reception feedback in response to the historical transmission data and the heartbeat reply in response to the heartbeat request; based on the bitmap information, the transmission data of the data group is determined through the sending window; the transmission data of each data group of the first end is concurrently transmitted to the second end; the reception feedback of the second end in response to the transmission data is obtained, and the bitmap information is updated according to the reception feedback; wherein the transmission data is merged into the historical transmission data, and the reception feedback is merged into the historical reception feedback; and the step of adjusting the sending window of the data group according to the continuous state of the interactive information between the first end and the second end is returned until the file to be synchronized completes data synchronization. The embodiment of the present invention obtains and updates the bitmap information of the first end and the second end in real time, and the present invention can accurately grasp the bitmap position and synchronization status of all data blocks under each data group in the file to be synchronized. This mechanism effectively avoids repeated data transmission and omission, and significantly improves the accuracy of data synchronization. At the same time, the dynamic sending window adjustment strategy based on bitmap information can flexibly respond to changes in network conditions and ensure that data is transmitted under optimal conditions, thereby improving synchronization efficiency. The present invention can efficiently realize dynamic synchronization of ship-shore narrowband network data. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] The accompanying drawings are used to provide a further understanding of the technical solution of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the technical solution of the present invention and do not constitute a limitation on the technical solution of the present invention.

[0069] Figure 1 A schematic diagram of an implementation environment for dynamic synchronization of ship-shore narrowband network data provided by an embodiment of the present invention;

[0070] Figure 2 A schematic flow chart of a method for dynamic synchronization of ship-shore narrowband network data provided by an embodiment of the present invention;

[0071] Figure 3 A schematic diagram of an extended process of a method for dynamic synchronization of ship-shore narrowband network data provided by an embodiment of the present invention;

[0072] Figure 4 A schematic diagram of an expansion process of adjusting a sending window provided in an embodiment of the present invention;

[0073] Figure 5 A schematic diagram of breakpoint data synchronization interaction provided by an embodiment of the present invention;

[0074] Figure 6 A schematic diagram of the sending process of data synchronization interaction provided by an embodiment of the present invention;

[0075] Figure 7 A schematic diagram of an extended process for updating bitmap information provided by an embodiment of the present invention;

[0076] Figure 8 A schematic diagram of the overall business process principle of the method for dynamic synchronization of ship-shore narrowband network data provided by an embodiment of the present invention;

[0077] Fig. 9 A schematic diagram of the structure of a ship-to-shore narrowband network data dynamic synchronization device provided by an embodiment of the present invention;

[0078] Fig.10 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0079] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[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 may be performed in a different order than the module division in the system or the order in the flowchart. The terms "first / S100", "second / S200", etc. in the specification, claims and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0081] Reference to "embodiments" in the present invention means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present invention. The appearance of the phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described in the present invention may be combined with other embodiments.

[0082] It is understandable that the ship-shore narrowband network data dynamic synchronization method provided in the embodiment of the present invention can be applied to any computer device with data processing and computing capabilities, and this 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 that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Optionally, the terminal is a smart phone, tablet computer, laptop computer, desktop computer, etc., but is not limited to this.

[0083] To facilitate the understanding of the technical solution of the present invention, the specific terms of the technical features that may appear in the embodiments of the present invention are first explained:

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

[0085] A drilling vessel is a ship dedicated to drilling submarine geological structures, mainly used for marine geological exploration. With the in-depth implementation of the national marine strategy, my country's drilling vessels are appearing more and more frequently in international oceans such as the Pacific Ocean. At this time, the only means of communication between the ship and the shore base is satellite.

[0086] TCP Transmission Control Protocol (TCP) is a connection-oriented, reliable, byte-stream-based transport layer communication protocol. TCP is designed to adapt to a layered protocol hierarchy that supports multi-network applications. Pairs of processes in host computers 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 a variety of communication systems from hard-wired connections to packet switching or circuit switching networks.

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

[0088] LZMA compression algorithm: Among the 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 chain compression method and applies a modified LZ77 algorithm at the bit level to achieve excellent compression efficiency, especially when processing highly repetitive data such as text and source code.

[0089] LZMA2 compression algorithm: As a successor to LZMA, LZMA2 further improves compression performance and multi-core processor support while maintaining a high compression rate. In practical applications, such as using 7-Zip software, choosing the LZMA2 compression method can often achieve a very high compression rate.

[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, which means that it is difficult to infer the original information from the hash value. The core significance of MD5 is to provide a data verification mechanism. By calculating the MD5 value of the data, it is possible to efficiently compare whether the data is consistent without directly comparing the data itself. It is achieved through complex mathematical operations, and even a small change in the data will result in a huge difference in the calculated MD5 value.

[0091] like Figure 1 FIG. 1 is a schematic diagram of an implementation environment provided by an embodiment of the invention. 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 to a network wirelessly or wired to complete data transmission and exchange.

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

[0093] In addition, the server 101 can also be a node server in the blockchain network. Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm.

[0094] The terminal 102 may be a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, etc., but is not limited thereto. The terminal 102 and the server 101 may be directly or indirectly connected via wired or wireless communication, which is not limited in the embodiment of the present invention.

[0095] Based on the example Figure 1 In the implementation environment shown, an embodiment of the present invention provides a method for dynamic synchronization of ship-shore narrowband network data. The following is explained using the example of the method for dynamic synchronization of ship-shore narrowband network data applied in the server 101. It can be understood that the method for dynamic synchronization of ship-shore narrowband network data can also be applied in the terminal 102.

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

[0097] S100, obtaining bitmap information of the first end and the second end; 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 completed synchronization, synchronizing, and waiting for synchronization;

[0099] Among them, in some specific implementations, the embodiments of the present invention also include a step of local data compression, which can be specifically implemented as follows:

[0100] There are generally many files to be transmitted on the ship side, mainly the test results of technical experiments, in formats including tables, texts, pictures and other files, and fewer high-definition videos. These data files need to be compressed before transmission. The present invention 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, a higher compression rate is still necessary. In the data transmission management regulations on board, it is not recommended to transmit high-definition video. This is because current videos are usually in compressed formats. Even if LZMA2 is used for recompression, the file compression rate will not be too high, and the video will take up a lot of bandwidth and affect the transmission of other files, so high-definition video files are usually synchronized by direct copying after the ship docks.

[0101] 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 invention is grouped according to 100M as the benchmark, that is, the sum of the file sizes of each group is about 100M. If a single file exceeds 100M, then this file is grouped separately. Then compression is performed for each group, and the compressed package name is the MD5 of all file names added together, so that a series of compressed packages will be 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 transfer failure rate. These compressed packages are transmitted synchronously one by one, and the present invention is for data synchronization of a single compressed package.

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

[0103] It should be understood that when local data compression is used, the transmitted verification information may include the file name, file size, file MD5, file creation time, last modification time, bitmap grouping and other information of the compressed package. This information is mainly used to determine whether breakpoint resumption is required.

[0104] Among them, in some embodiments, such as Figure 3As shown, the method may also include the following steps: T100, splitting the file to be synchronized into several data blocks based on a preset transmission protocol, and then sequentially marking the block ID of each data block; T200, based on a preset grouping size, sequentially acquiring the corresponding data blocks from the file to be synchronized along the direction of the block ID from small to large to construct data groups, and then sequentially marking the grouping ID of each data group; T300, performing a remainder operation on the block ID and the preset grouping size to obtain the grouping position of each data block in its corresponding data group; T400, determining the bitmap position of each data block based on the grouping ID and the grouping position.

[0105] For example, in some specific implementations, when the shore side receives a data synchronization request, it checks the files that have been transmitted by the shore side. The judgment process is mainly as follows:

[0106] 1) Check the file name to see if the file exists on the shore. If it does not exist, it means that the file is being transmitted for the first time. If it does not exist, continue to compare the file's MD5;

[0107] 2) Check the file MD5 to see if the MD5 of the file on the shore is consistent with the MD5 of the target file. If they are inconsistent, it means that the target file has changed and needs to be retransmitted. If they are consistent, continue to compare the file sizes.

[0108] 3) Check the bitmap information and file size of the present invention. If they are consistent, it means that the file has been transferred before, and you can choose to resume the transfer. If they are inconsistent, it means that the target file has changed and needs to be retransmitted. This step is necessary because the file is stored in the cache before the successful transmission, and the cache may be tampered with or cleared.

[0109] 4) Check the bitmap information of all packets. If all data packets have been received, it means that the data synchronization is successful. Otherwise, it needs to be transmitted from the beginning or retransmitted from the breakpoint. If the data has been transmitted successfully, check the final verification mark of the shore end. If the verification has been completed, reply that the ship end synchronization is successful, otherwise it needs to be finalized.

[0110] Among them, the bitmap information is used to mark the situation of receiving files on the shore side. The present invention uses a secondary bitmap. Simply put, the files to be transmitted are divided into multiple groups according to SubSize, and each group calculates its own bitmap separately. Refer to the following formula, FileSize is the file size, SubSize is the group 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] Then the bitmap size of each group is Bytes, each position of the bitmap is 0 means no data is received, and 1 means data is received. For each block ID, its corresponding group ID can be calculated by formula (3), and within the corresponding group, its position in the bitmap can be calculated by formula (4):

[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. This is done to facilitate the concurrent transmission of multiple packet data. This feature is one of the core points of the present invention and is also impossible to achieve in previous work.

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

[0117] The interactive information includes transmission information and feedback information; the transmission information includes historical transmission data sent by the first end to the second end and heartbeat requests sent regularly; the feedback information includes historical reception feedback in response to historical transmission data and heartbeat replies in response to heartbeat requests;

[0118] It should be noted that the continuous state includes continuity and sequence number difference, and continuity includes continuity or discontinuity; in some embodiments, such as Figure 4 As shown, step S200 may include the following steps: S201, obtaining the latest data sent by the first end from the historical transmission data as the target transmission data, and obtaining the latest response data of the second end from the historical reception feedback as the target reception feedback; S202, using the latest heartbeat request sent by the first end as the target heartbeat request, and using the latest heartbeat reply of the second end as the target heartbeat reply; S203, determining a first continuous state according to the Seq sequence number carried by the target transmission data and the target reception feedback; the first continuous state includes a first continuity and a first sequence number difference; S204, determining a second continuous state according to the heartbeat request and the Seq sequence number carried by the heartbeat reply; the second continuous state includes a second continuity and a second sequence number difference; S205, adjusting the window size of the sending window based on the first continuous state or the second continuous state.

[0119] Among them, in some embodiments, 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: when the first continuity is continuous, the window size is expanded; otherwise, the first sequence number difference is determined; when the first sequence number difference is greater than a preset difference threshold, the window size is reduced, otherwise, the window size is not adjusted; when the second continuity is continuous, the window size is not adjusted; otherwise, the window size is reduced; wherein the expansion processing includes doubling expansion, step expansion and no expansion, and the reduction processing includes halving and stepwise reduction; the expansion processing and reduction processing methods 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 in the case of window expansion, to prevent possible instantaneous network congestion.

[0121] For example, in some specific implementations, each group has its own sending window, that is, different groups can be carried out concurrently, that is, multiple data can be transmitted simultaneously, which is one of the core points of the present invention. Assume that the maximum number of concurrent groups is ParallelNum (which can be customized, at least 1, usually configured as 3 to 5), that is, at most three groups are carried out concurrently. The sending window of each group is dynamically calculated and adjusted, and the adjustment method of the windows of different groups is consistent, so here we will describe the adjustment method of the window from the perspective of a group.

[0122] The window size WindowSize starts at 1. Each time a reply is received from the shore, the window will double (refer to formula 5) or halve (refer to formula 8). When the window exceeds the intermediate critical value MidSize, the window expansion operation increases by 1 each time (refer to formula 6), instead of doubling, and the window reduction operation decreases by 1 each time (refer to formula 9), instead of halving. When the window exceeds the maximum critical value FinSize, the window will not grow, that is, the maximum critical value of the position (refer to 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 critical value MidSize and the maximum critical value FinSize can be customized, which are generally based on the network communication bandwidth and combined with actual experience. Based on the scenario of ship-shore data synchronization, through a large number of tests, the general MidSize is 8 and the FinSize is 12.

[0129] For a group, the window expansion or contraction operation is mainly based on the following rules:

[0130] Case 1: When the packet is received from the shore, if the Seq numbers are continuous, it means that the data is received successfully soon and the window is expanded. The continuous Seq numbers here mean that if the ship sends Seq1 and the shore replies Seq1+1, it can be considered continuous.

[0131] Case 2: When the packet is received at the shore end, if the Seq numbers are discontinuous but the Seq difference does not exceed MaxSeqLen (which can be customized and is 2 by default), it indicates that the data is received normally and the window remains unchanged.

[0132] Case 3: When the packet is received at the shore end, if the Seq number is discontinuous but the Seq difference exceeds MaxSeqLen, it indicates that the data reception is a bit blocked and the window is reduced.

[0133] Case 4: When the packet receives the heartbeat reply from the shore, if the Seq number is continuous, the window remains unchanged. Generally, the heartbeat frequency is once every 1 second, which reflects the network delay a bit slowly, so the window is chosen to remain unchanged here.

[0134] Case 5: When receiving the heartbeat reply from the shore, if the Seq number is discontinuous, the window is reduced. When the heartbeat Seq is discontinuous, it means that the network is severely congested and the window must be reduced.

[0135] Case 6: When there are multiple transmission packets (i.e. ArraySize ≥ 2), and after a packet is transmitted, a new packet is started to participate in the transmission. At this time, all packets compete for window expansion opportunities, and the number of window expansion opportunities does not exceed half of the number of packets. First come first served, that is, the first to issue a window expansion request will have its window expanded, and the windows of other groups remain unchanged. If the windows of all groups are expanded, it may cause instantaneous network congestion, so here the window expansion is carried out on a competitive basis.

[0136] Case 7: After the bitmap is updated, if a packet is suspected to be lost and the number does not exceed MaxLostNum (which can be customized and the default value is 3), the window remains unchanged.

[0137] Case 8: After the bitmap is updated, if a packet is suspected to be lost and the number exceeds MaxLostNum, the window is reduced.

[0138] Case 9: If you encounter the above situations at the same time, at this time, if all window expansion operations are performed or both expansion operations and unchanged operations are performed, the window will be expanded once; if all window reduction operations are performed or both reduction operations and unchanged operations are performed, the window will be reduced once; in other cases, the window remains unchanged.

[0139] In general, the sending window is dynamically adjusted based on a variety of situations. The window is dynamically adjusted when receiving a data reception reply from the shore, a heartbeat reply, an updated bitmap, etc. Based on the dynamic window adjustment strategy, flexible data transmission control is achieved, thereby improving the transmission speed.

[0140] S300, determining transmission data of the data packet through a sending window based on the bitmap information;

[0141] Among them, when the sending window is expanded, the data blocks with forward bitmap positions in the data blocks waiting for synchronization are further included in the sending window, and the synchronization status of the corresponding data blocks is changed to synchronizing; similarly, when the sending window is reduced, the data blocks with backward bitmap positions in the data blocks being synchronized are moved out of the sending window, and the synchronization status of the corresponding data blocks is changed to waiting for synchronization; accordingly, the embodiment of the present invention can adopt out-of-order transmission.

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

[0143] For example, in some specific implementations, the embodiments of the present invention may adopt out-of-order transmission, which may be implemented as follows:

[0144] Send data chunks out of order:

[0145] For data transmission of a single packet, if some of the data in the packet is not synchronized, prepare to send the data blocks out of order. Figure 5 The data status is divided into three states: synchronizing, waiting for synchronization and completing synchronization. It can be seen that packet 01 has been synchronized, packets 02-06 are being synchronized, and data block 03 of packet 02 is suspected to be lost and is currently being resent.

[0146] The window for each group is dynamically calculated. If the number of data blocks in the synchronized state, SyningNum, is less than the current transmission window size WindowSize (i.e., SyningNum < WindowSize), data will be selected for transmission or retransmission.

[0147] If the number of data blocks in the synchronized state, SyningNum, is not less than the current transmission window size WindowSize (i.e., SyningNum ≥ WindowSize), the current state remains unchanged. When it is determined that a certain piece of data is suspected of being lost, the state of this data is modified to be pending synchronization. At this time, the number of synchronized state data packets decreases, and SyningNum = SyningNum - 1. This operation is continuously executed until SyningNum == WindowSize before stopping.

[0148] How to determine that a certain data packet is suspected of being lost? If the data is in the state of block - by - block processing synchronization and the received SeqID of the bitmap update exceeds the SeqID for sending this data block, then this data block is suspected of being lost.

[0149] Different from existing methods, in the present invention, re - transmitted data packets are regarded the same as other data packets. As long as there is a slot in the transmission window, data will be sent. If the transmission window is full, sending will stop. At this time, data suspected of being lost will not be re - transmitted until there is a slot in the window.

[0150] Receive data blocks out of order and store them in order:

[0151] The shore end will receive multiple UDP data packets, which include information such as file ID, block ID, data block, SeqID, etc. Determine which file the data belongs to according to the file ID, and determine the block position according to the block ID. Based on the block ID, calculate ArrayID through formula (3) and calculate ArrayIndex through formula (4), that is, clarify the specific position in the group.

[0152] Considering network factors and resume - from - breakpoint re - transmission, 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. Those not received temporarily belong to "breakpoint" data. At the same time, the shore end may receive data packets with the same file ID and block ID multiple times. If they have already been saved, the duplicate data packets are directly discarded.

[0153] Reference Figure 6 In the data sending process, under normal circumstances, the repeated process of the ship end sending data and the shore end receiving data easily affects the transmission efficiency. Therefore, in the present invention, the ship end will dynamically adjust the transmission window to regulate the sending rhythm, and the shore end will regularly verify the data and reply to the ship end. When it is clear that data is lost, the ship end re - transmits the data according to the transmission window to achieve resume - from - breakpoint transmission.

[0154] S500, obtaining reception feedback from the second end in response to the transmission data, and updating the bitmap information according to the reception feedback;

[0155] Among them, the transmission data is merged into the historical transmission data, and the reception feedback is merged into the historical reception feedback;

[0156] It should be noted that the received feedback includes the bitmap position of the data block that has been received; in some embodiments, such as Figure 7 As shown, updating the bitmap information according to the received feedback may include the following steps: S501, based on the bitmap position, comparing the data blocks included in the transmitted data with the data blocks that have been completed received and included in the received feedback, and determining the target data blocks that have completed synchronization; S502, updating the synchronization status of the target data blocks to complete synchronization.

[0157] S600, returning 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 data synchronization of the to-be-synchronized file is completed.

[0158] In some embodiments, the method may further include the following steps: the second end periodically replies to the first end regarding the status of data block reception in response to received information; wherein the received information includes block verification requests and heartbeat requests periodically sent by the first end; and the bitmap information is secondary updated based on the status of data block reception.

[0159] For example, in some specific implementations, the data block reception status may be replied periodically, which may be implemented as follows:

[0160] The shore end will receive a large number of data packets one after another and store them in sequence. If the shore end meets the following conditions, it will immediately reply to the data block reception status:

[0161] Case 1: Every time data is received, the data block reception status will be replied.

[0162] Case 2: When receiving a block verification request, immediately reply with the data block reception status.

[0163] Case 3: When receiving a heartbeat request, immediately reply with the data block reception status.

[0164] It should be noted that when multiple packets are sent concurrently, in most cases, the shore end will receive multiple packets at the same time, process the received data first, and then reply with the received relevant packet bitmap information. Through most experiments, it is often seen that one reply packet replies to the reception of multiple data blocks.

[0165] In general, if any of Case 1, Case 2 and Case 3 is met, the system will actively send a reply to the block reception status, including file ID, group ID, group bitmap, SeqID+1, etc. If there are multiple groups, they will be sent together.

[0166] Among them, when the ship end updates the bitmap and finds that all the data blocks of some groups have been synchronized, it is necessary to perform group data verification. At this time, the ship end will first start a new group to participate in the transmission, then all groups compete for the expansion window, and finally send a verification request. The verification request includes the file ID, the ArrayID of the group that has been transmitted, and the corresponding MD5 check value, SeqID, etc. If multiple groups have completed synchronization, they will be checked together in blocks. Each group is only verified once.

[0167] For example, in some specific implementations, the ship will periodically send a heartbeat request, and the request content includes information such as the heartbeat SeqID and file ID, and each heartbeat is sent. The sending frequency SendFrequency can be customized and controlled, generally once every 1s (recommended between 500ms and 1s). The main reasons for setting the heartbeat request are as follows:

[0168] 1) Determine the network status. The ship can determine the network status through the heartbeat request reply. If the heartbeat reply is not received for many times, it means that the network quality is particularly poor. At this time, the sending progress will be adjusted or even stopped.

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

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

[0171] In some embodiments, the method may further include at least one of the following steps: obtaining first verification information of the transmitted data, verifying and calculating the first synchronization data that the second end completes synchronization in response to the transmitted data to obtain second verification information; performing a first verification based on the first verification information and the second verification information; wherein, when the result of the first verification is inconsistent, performing a first retransmission feedback to the first end; obtaining third verification information of the file to be synchronized, verifying and calculating the second synchronization data that the second end completes synchronization in response to the file to be synchronized to obtain fourth verification information; performing a second verification based on the third verification information and the fourth verification information; wherein, when the result of the second verification is inconsistent, performing a second retransmission feedback to the first end.

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

[0173] If A1 and A2 are consistent, reply with verification consistency. If A1 and A2 are inconsistent, it means that the data may be tampered with, then reset the bitmap state of the packet to wait for synchronization, reply with verification inconsistency, and reply with the latest incremental bitmap. This is also one of the core points of the present invention, that is, data that fails the block verification can be actively retransmitted.

[0174] The shore end will reply with the file ID, the ArrayID of the group that has been transferred, the verification result, SeqID+1, etc., and will also send the bitmap information that is currently being transmitted.

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

[0176] For example, in some specific implementations, based on the ship-side bitmap, after the ship-side determines that all data has been received, it indicates that data synchronization is successful. At this time, a verification request will be sent, and the request content is mainly the information of the current transmission file (file name, file ID, MD5, file size, last modification time, etc.).

[0177] After receiving the verification request, the shore end will recalculate the MD5 of the file and then compare it with the requested MD5. If they are consistent, it means that the file transfer is successful. If they are inconsistent, it means that some data packets may have been tampered with. In most cases, the MD5 is consistent.

[0178] The shore side replies with the MD5 verification status, which mainly includes the information of the currently transferred file (file name, file ID, MD5, file size, last modified time, etc.). After receiving the reply, the shore side records the status of this transmission, marks the file as having completed synchronization, and notifies the user. If the MD5 is consistent, the user is notified that the file transfer is successful, otherwise the user is notified that the intermediate data has been tampered with and needs to be resynchronized (the data will not be reset and cleared here, and the user needs to actively retransmit). Simply put, 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 reminded and can choose to retransmit.

[0179] In order to explain the principle of the technical solution of the present invention in detail, the overall process of the present invention is described below in combination with some specific embodiments. It is easy to understand that the following is an explanation of the technical principle of the present invention and cannot be regarded as a limitation of the present invention.

[0180] First of all, it should be explained that there are existing work ideas: currently, data synchronization from the ship end to the shore end is divided into three stages: metadata preparation, data synchronization and final verification. The transmission characteristic is that data is sent in a fixed window, and all data is sent or resent one by one in sequence, and true out-of-order sending is not achieved.

[0181] Disadvantages of current mainstream solutions:

[0182] 1) Slow speed: Currently, data from ship to shore is mainly transmitted via satellite. The satellite bandwidth is relatively low, resulting in slow data synchronization.

[0183] 2) Poor experience: Considering the low satellite bandwidth and the fact that data synchronization and onboard technicians need to be connected to the Internet, there will be bandwidth competition, resulting in a poor Internet experience for users.

[0184] 3) Low synchronization success rate: Currently, data synchronization is mainly based on TCP transmission. The integrity of data transmission is theoretically guaranteed, but considering the low bandwidth of satellites, data transmission often fails halfway through.

[0185] Disadvantages of existing work plans:

[0186] 1) Bitmap storage accounts for a large proportion: All data is organized based on the first-level bitmap, the array organization is a bit simple, and the efficiency of bitmap information exchange is low;

[0187] 2) Data is sent serially in order: All data blocks are sent or resent one by one. The design does not allow for concurrent sending of multiple range segment data blocks (for example, transmission from the beginning and transmission from the end cannot be concurrent at the same time).

[0188] 3) Fixed send window: When the network is extremely congested, the fixed window reacts slowly, still causing some bandwidth waste and resulting in a decrease in data transmission speed.

[0189] In view of this, the present invention proposes a method for dynamically synchronizing the data disorder of the ship-to-shore number. Figure 8 , the specific steps are as follows:

[0190] Step 1. Local data compression. There are generally many files to be transmitted on the ship side, mainly the test results of technical experiments, in formats including tables, texts, pictures and other files, and fewer high-definition videos. These data files need to be compressed before transmission. The present invention 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, a higher compression rate is still necessary. In the data transmission management regulations on board, it is not recommended to transmit high-definition video. This is because current videos are usually in compressed formats. Even if LZMA2 is used for re-compression, the file compression rate will not be too high, and the video will take up a lot of bandwidth and affect the transmission of other files, so high-definition video files are 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 invention is grouped according to 100M as the benchmark, that is, the sum of the file sizes of each group is about 100M. If a single file exceeds 100M, then this file is grouped separately. Then compression is performed for each group, and the compressed package name is the MD5 of all file names added together, so that a series of compressed packages will be 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 transfer failure rate. These compressed packages are transmitted synchronously one by one, and the present invention is for data synchronization of a single compressed package.

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

[0193] Regarding grouping, for example, if 7 files A (size 80M), B (size 17M), C (size 60M), D (size 60M), E (size 70M), F (size 80M), G (170M) have been sorted by 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 around 100M, the compressed package name is MD5(AB);

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

[0196] 3) E (size 70M) is a separate group. E is 70M, 30M short of 100M, but E+F=150M, 50M more than 100M, so E is a separate group, and the compressed package name is MD5(E);

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

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

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

[0200] Step 2. Initiate a ship-side data synchronization request. The ship sends a data synchronization request, which is forwarded to the shore via satellite. It mainly includes detailed information about the compressed package of transmitted data, including the file name, file size, file MD5, file creation time, last modification time, bitmap grouping, etc. This information is mainly used to determine whether breakpoint resuming is required.

[0201] Step 3. Check data synchronization. When the shore side receives the data synchronization request, it will check the files that have been transferred on the shore side. The judgment process is mainly as follows:

[0202] 1) Check the file name to see if the file exists on the shore. If it does not exist, it means that the file is being transmitted for the first time. If it does not exist, continue to compare the file's MD5;

[0203] 2) Check the file MD5 to see if the MD5 of the file on the shore is consistent with the MD5 of the target file. If they are inconsistent, it means that the target file has changed and needs to be retransmitted. If they are consistent, continue to compare the file sizes.

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

[0205] 4) Check the bitmap information of all packets. If all data packets have been received, it means that the data synchronization is successful. Otherwise, it needs to be transmitted from the beginning or retransmitted from the breakpoint. If the data has been transmitted successfully, check the final verification mark of the shore end. If the verification has been completed, reply that the ship end synchronization is successful, otherwise it needs to be finalized.

[0206] The bitmap information is used to mark the situation of receiving files on the shore side. The present invention uses a secondary bitmap. In short, the files to be transmitted are divided into multiple groups according to SubSize, and each group calculates its own bitmap separately. Referring to the following formula, FileSize is the file size, SubSize is the group 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] Then the bitmap size of each group is Bytes, each position of the bitmap is 0 means no data is received, and 1 means data is received. For each block ID, its corresponding group ID can be calculated by formula (3), and within the corresponding group, its position in the bitmap can be calculated by formula (4):

[0209]

[0210] ArrayIndex=ID%ArraySize (4)

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

[0212] Assuming the data block ID is 5, the ArrayID of the group it belongs to is The bitmap position in group 0 is 5%1024=5, that is, the bitmap position of the data block ID 5 is position 5 in group 0.

[0213] Assuming the data block ID is 2299, the ArrayID of the group it belongs to is The bitmap position in group 2 is 2299%1024=251, that is, the bitmap position of the data block ID 2299 is actually 251 in group 2.

[0214] Compared with the primary bitmap, the biggest change of the secondary bitmap is that it is cut into multiple sub-bitmaps. This is done to facilitate the concurrent transmission of multiple packet data. This feature is one of the core points of the present invention and is also impossible to achieve in previous work.

[0215] Step 4. Data synchronization status reply on the shore side. After the inspection is completed, the monitored status will be directly fed back to the ship side, mainly the file information that already exists on the shore side (file name, MD5, file bitmap, file size, last modified time, transmission progress, etc.). Note that the bitmap here is the full bitmap, that is, the bitmap information of each group. If the data of a group has been transmitted, it will be directly marked as completed, and the bitmap will not be transmitted. This is to reduce the transmission bandwidth.

[0216] Step 5. Dynamic adjustment of the sending window. Each group has its own sending window, that is, different groups can be carried out concurrently, that is, multiple data channels can be transmitted simultaneously, which is one of the core points of the present invention. Assume that the maximum concurrent number of groups is ParallelNum (which can be customized, at least 1, usually configured as 3 to 5), that is, at most three groups are carried out concurrently. The sending window of each group is dynamically calculated and adjusted, and the adjustment method of the windows of different groups is consistent, so here we will describe the window adjustment method from the perspective of a group.

[0217] The window size WindowSize starts at 1. Each time a reply is received from the shore, the window will double (refer to formula 5) or halve (refer to formula 8). When the window exceeds the intermediate critical value MidSize, the window expansion operation increases by 1 each time (refer to formula 6), instead of doubling, and the window reduction operation decreases by 1 each time (refer to formula 9), instead of halving. When the window exceeds the maximum critical value FinSize, the window will not grow, that is, the maximum critical value of the position (refer to 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 critical value MidSize and the maximum critical value FinSize can be customized, which are generally based on the network communication bandwidth and combined with actual experience. Based on the scenario of ship-shore data synchronization, through a large number of tests, the general MidSize is 8 and the FinSize is 12.

[0224] For a group, the window expansion or contraction operation is mainly based on the following rules:

[0225] Case 1: When the packet is received from the shore, if the Seq numbers are continuous, it means that the data is received successfully soon and the window is expanded. The continuous Seq numbers here mean that if the ship sends Seq1 and the shore replies Seq1+1, it can be considered continuous.

[0226] Case 2: When the packet is received at the shore end, if the Seq numbers are discontinuous but the Seq difference does not exceed MaxSeqLen (which can be customized and is 2 by default), it indicates that the data is received normally and the window remains unchanged.

[0227] Case 3: When the packet is received at the shore end, if the Seq number is discontinuous but the Seq difference exceeds MaxSeqLen, it indicates that the data reception is a bit blocked and the window is reduced.

[0228] Case 4: When the packet receives the heartbeat reply from the shore, if the Seq number is continuous, the window remains unchanged. Generally, the heartbeat frequency is once every 1 second, which reflects the network delay a bit slowly, so the window is chosen to remain unchanged here.

[0229] Case 5: When receiving the heartbeat reply from the shore, if the Seq number is discontinuous, the window is reduced. When the heartbeat Seq is discontinuous, it means that the network is severely congested and the window must be reduced.

[0230] Case 6: When there are multiple transmission packets (i.e. ArraySize ≥ 2), and after a packet is transmitted, a new packet is started to participate in the transmission. At this time, all packets compete for window expansion opportunities, and the number of window expansion opportunities does not exceed half of the number of packets. First come first served, that is, the first to issue a window expansion request will have its window expanded, and the windows of other groups remain unchanged. If the windows of all groups are expanded, it may cause instantaneous network congestion, so here the window expansion is carried out on a competitive basis.

[0231] Case 7: After the bitmap is updated, if a certain packet is suspected of being lost and the number does not exceed MaxLostNum (which can be customized, default is 3), the window remains unchanged.

[0232] Case 8: After the bitmap is updated, if a certain packet is suspected of being lost and the number exceeds MaxLostNum, the window is reduced.

[0233] Case 9: If the above situations are encountered simultaneously, at this time, if all are window expansion operations or there are both expansion operations and operations to keep unchanged, the window is expanded once; if all are window reduction operations or there are both reduction operations and operations to keep unchanged, the window is reduced once; in other cases, the window remains unchanged.

[0234] Generally speaking, the sending window is dynamically adjusted based on various situations. When receiving shore - end data reception replies, heartbeat replies, bitmap updates, etc., the window is dynamically adjusted. Based on the dynamic window adjustment strategy, flexible control of data transmission is achieved, thereby improving the transmission speed.

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

[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), then data will be selected for sending or re - transmission.

[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), then the current state remains unchanged. When it is determined that a certain data is suspected of being lost, the status of the data is modified to waiting for synchronization. At this time, the number of synchronized status data packets decreases, and SyningNum = SyningNum - 1. This operation is continuously executed until SyningNum == WindowSize.

[0238] How to determine that a certain data packet is suspected of being lost? If the data block is in the in - synchronization state of processing and the SeqID received for the bitmap update exceeds the SeqID for sending this data block, then this data block is suspected of being lost.

[0239] Unlike the existing methods, the present invention treats retransmitted data packets as other data packets and sends data as long as there is room in the sending window. If the sending window is full, the sending will stop and the data suspected of packet loss will not be retransmitted until there is room in the window.

[0240] Step 7. Receive data blocks out of order and store them in order. The shore side will receive multiple UDP packets, which include file ID, block ID, data block, SeqID and other information. Determine which file the data belongs to based on the file ID, and determine the block position based on the block ID. Based on the block ID, calculate ArrayID through formula (3), and calculate ArrayIndex through formula (4), which clarifies the specific position in the group.

[0241] Taking into account 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 of block ID. The data packets that have not been received temporarily are "breakpoint" data. At the same time, the shore end may receive data packets with the same file ID and block ID multiple times. If they have been saved, the duplicate data packets will be discarded directly.

[0242] refer to Figure 6 In the data transmission process, under normal circumstances, the ship sends data and the shore receives data repeatedly, which easily affects the transmission efficiency. Therefore, the ship in the present invention will dynamically adjust the sending window and adjust the sending rhythm. The shore will regularly check the data and reply to the ship. When it is clear that the data is lost, the ship will retransmit the data according to the sending window to achieve breakpoint resumption.

[0243] Step 8. Regularly reply to the data block reception status. The shore end will receive a large number of data packets one after another and store them in sequence. If the shore end meets the following conditions, it will immediately reply to the data block reception status:

[0244] Case 1: Every time data is received, the data block reception status will be replied.

[0245] Case 2: When receiving a block verification request, immediately reply with the data block reception status.

[0246] Case 3: When receiving a heartbeat request, immediately reply with the data block reception status.

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

[0248] In general, if any of Case 1, Case 2 and Case 3 is met, the system will actively send a reply to the block reception status, including file ID, group ID, group bitmap, SeqID+1, etc. If there are multiple groups, they will be sent together.

[0249] Step 9. Send block verification requests regularly. When the ship side updates the bitmap and finds that all the data blocks of some groups have been synchronized, it is necessary to perform group data verification. At this time, the ship side will first start a new group to participate in the transmission, then all groups compete for the expansion window, and finally send a verification request. The verification request includes the file ID, the ArrayID of the group that has been transmitted, and the corresponding MD5 check value, SeqID, etc. If multiple groups have completed synchronization, block verification will be performed together. Each group is only verified once.

[0250] Step 10. Verify the received data. When receiving the verification request, the ArrayID is calculated based on the block ID using formula (3), and then the corresponding MD5 verification value is calculated. Assume that the MD5 verification value calculated by the shore side is A1, and the MD5 verification value calculated by the ship side is A2.

[0251] If A1 and A2 are consistent, reply with verification consistency. If A1 and A2 are inconsistent, it means that the data may be tampered with, then reset the bitmap state of the packet to wait for synchronization, reply with verification inconsistency, and reply with the latest incremental bitmap. This is also one of the core points of the present invention, that is, data that fails the block verification can be actively retransmitted.

[0252] The shore end will reply with the file ID, the ArrayID of the group that has been transferred, the verification result, SeqID+1, etc., and will also send the bitmap information that is currently being transmitted.

[0253] Step 11. Reply to the data verification status and selectively retransmit. If the verification is consistent, the packet data is synchronized successfully and the verification is successful. If the verification is inconsistent, reset the bitmap state of the packet to wait for synchronization and retransmission is required. Based on experience, this situation is rare.

[0254] Step 12. Send a heartbeat request. The ship will periodically send a heartbeat request, which includes information such as the heartbeat SeqID and file ID. The heartbeat is sent once each time. The frequency of sending SendFrequency can be customized and is generally sent once every 1 second (recommended between 500ms and 1 second). The main reasons for setting a heartbeat request are as follows:

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

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

[0257] Step 13. Heartbeat reply. After receiving the heartbeat request, the shore side will process it and reply to the ship side with the heartbeat SeqID, file ID, bitmap start ID, incremental bitmap information, etc. The ship side needs to make a network quality judgment based on the heartbeat reply. For how to make the judgment, refer to step 5.

[0258] Step 14. Data synchronization is successful, and a verification request is sent. 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 will be sent, and the request content is mainly the information of the current transmission file (file name, file ID, MD5, file size, last modification time, etc.).

[0259] Step 15. Local data verification. After receiving the verification request, the shore end will recalculate the MD5 of the file and then compare it with the requested MD5. If they are consistent, it means that the file transfer is successful. If they are inconsistent, it means that some data packets may have been tampered with. In most cases, the MD5 is consistent.

[0260] Step 16. Reply with the data verification status. The shore side replies with the MD5 verification status, which is mainly the information of the currently transmitted file (file name, file ID, MD5, file size, last modification time, etc.). After receiving the reply, the shore side records the status of this transmission, marks that the file has been synchronized, and notifies the user. If the MD5 is consistent, the user is notified that the file transfer is successful, otherwise the user is notified that the intermediate data has been tampered with and needs to be resynchronized (the data will not be reset and cleared here, and the user needs to actively retransmit). Simply put, 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. The user will be reminded and can choose to retransmit.

[0261] When steps 14 to 16 are completed, the file will be marked as synchronized, and then another 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 is suddenly disconnected, the ship side will be unable to receive the data verification reply. At this time, the file is still in synchronization. After the network returns to normal, the ship side will resend the verification request until the verification reply is received. The transmission process of the file is truly completed. It should also be noted that the SeqID mentioned in the present invention is a global self-incrementing variable. After each use, SeqID = SeqID + 1. SeqID is mainly used to correspond to request packets and reply packets.

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

[0263] 1) Preparation phase, including steps 1 to 4. This phase mainly clarifies the information of the file to be transmitted on the shore side and synchronizes the latest bitmap. It is the data preparation phase before transmission.

[0264] 2) The synchronization phase includes steps 5 to 13. This phase is mainly responsible for data synchronization and bitmap synchronization. The sending rhythm is dynamically adjusted through the heartbeat and block verification mechanism to improve the file transfer efficiency.

[0265] 3) Verification phase, including steps 14 to 16, this phase is mainly the final data verification.

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

[0267] 1) Introduce a secondary bitmap to control the data sending process, optimize the data organization structure, and facilitate the out-of-order and concurrent sending of data

[0268] 2) Dynamically adjust the sending window to make full use of idle bandwidth, reduce data retransmission bandwidth, and increase transmission speed.

[0269] 3) Intermediate data is verified regularly and supports breakpoint resumption, ensuring data integrity from the start to the completion of data download.

[0270] On the other hand, Fig. 9 As shown, the embodiment of the present invention provides a ship-shore narrowband network data dynamic synchronization device 900, which may include:

[0271] The first module 901 is used to obtain bitmap information of the first end and the second end; the bitmap information includes the bitmap position and synchronization status of all data blocks under each data group in the file to be synchronized;

[0272] A second module 902, configured to adjust a sending window of data packets according to a continuous state of interaction information between the first end and the second end;

[0273] The interactive information includes transmission information and feedback information; the transmission information includes historical transmission data sent by the first end to the second end and heartbeat requests sent regularly; the feedback information includes historical reception feedback in response to historical transmission data and heartbeat replies in response to heartbeat requests;

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

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

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

[0277] Among them, the transmission data is merged into the historical transmission data, and the reception feedback is merged into the historical reception feedback;

[0278] The sixth module 906 is used 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 may further include:

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

[0281] An eighth module is used to obtain corresponding data blocks from the to-be-synchronized file in order from small to large block IDs based on a preset group size to construct data groups, and then sequentially mark the group ID of each data group;

[0282] A ninth module is used to perform a remainder operation on the block ID and the preset group size to obtain the group position of each data block in its corresponding data group;

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

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

[0285] An eleventh module is used to periodically reply to the first end about the data block reception status in response to the received information through the second end;

[0286] The received information includes a block verification request and a heartbeat request periodically sent by the first end;

[0287] The twelfth module is used to perform secondary update on the bitmap information based on the data block reception status.

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

[0289] A thirteenth module is used to obtain first verification information of the transmission data, verify and calculate the first synchronization data of the second end in response to the transmission data to complete synchronization to obtain second verification information; and perform a first verification based on the first verification information and the second verification information;

[0290] When the result of the first check is inconsistent, a first retransmission feedback is performed to the first end;

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

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

[0293] The contents of the method embodiments of the present invention are all applicable to the device embodiments. The functions specifically 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 method embodiments.

[0294] On the other hand, an embodiment of the present invention further provides an electronic device, the electronic device comprising a memory and a processor, the memory storing a computer program, and the processor implementing the above-mentioned hydrate stability region bottom boundary prediction method when executing the computer program. The electronic device can be any intelligent terminal including a tablet computer, a car computer, etc.

[0295] It can be understood that the contents of the above method embodiments are all applicable to the present device embodiments, the functions specifically implemented by the present 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 method embodiments.

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

[0297] The processor 1001 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an 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 in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1002 can store an operating system and other application programs. When the technical solution provided in the embodiment of this specification is implemented by software or firmware, the relevant program code is stored in the memory 1002, and the processor 1001 calls and executes the network node population optimization method of the embodiment of the present invention;

[0299] Input / output interface 1003, used to implement information input and output;

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

[0301] A bus 1005 , which transmits information between various components of the device (e.g., the processor 1001 , the memory 1002 , the input / output interface 1003 , and the communication interface 1004 );

[0302] The processor 1001 , the memory 1002 , the input / output interface 1003 and the communication interface 1004 are connected to each other in communication within the device via the bus 1005 .

[0303] The electronic device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separated, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0304] The contents of the method embodiments of the present invention are all applicable to the electronic device embodiments. The functions specifically implemented by the electronic 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 method embodiments.

[0305] Another aspect of an embodiment of the present invention further provides a computer-readable storage medium, wherein the storage medium stores a program, and the program is executed by a processor to implement the above method.

[0306] It should be noted that the computer-readable medium shown in the embodiment of the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, 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 to Only Memory, CD to ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer readable signal media may also be any computer readable medium other than computer readable storage media, which may send, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer readable medium may be transmitted using any suitable medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0307] The contents of the method embodiments of the present invention are all applicable to the computer-readable storage medium embodiments. The functions specifically implemented by the computer-readable storage medium 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 method embodiments.

[0308] The embodiment of the present invention also discloses a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. A processor of a computer device can read the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the above method.

[0309] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0310] It should be noted that, although several modules of the device for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to an embodiment 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. On the contrary, the features and functions of one module or unit described above can be further divided into being embodied by multiple modules or units.

[0311] Through the description of the above implementation, it is easy for those skilled in the art to understand that the example implementation described here can be implemented by software, or by software combined with necessary hardware. Therefore, the technical solution according to the implementation of the present invention can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD to ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, including several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the implementation of the present invention.

[0312] In some selectable embodiments, the function / operation mentioned in the block diagram may not occur in the order mentioned in the operation diagram. For example, depending on the function / operation involved, the two boxes shown in succession can actually be executed substantially simultaneously or the boxes can sometimes be executed in reverse order. In addition, the embodiment presented and described in the flow chart of the present invention is provided by way of example, for the purpose of providing a more comprehensive understanding of the technology. The disclosed method is not limited to the operation and logic flow presented by the present invention. Selectable embodiments are expected, wherein the order of various operations is changed and the sub-operation of a part described as a larger operation is performed independently.

[0313] In addition, although the present invention is described in the context of functional modules, it should be understood that, unless otherwise specified, one or more of the functions and / or features can be integrated into 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 is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the present invention. More specifically, in view of the properties, functions and internal relationships of various functional modules in the device disclosed in the present invention, the actual implementation of the module will be understood within the conventional skills of engineers. Therefore, those skilled in the art can implement the present invention set forth in the claims without excessive experimentation using ordinary techniques. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of the present invention, which is determined by the full scope of the appended claims and their equivalents.

[0314] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0315] The logic and / or steps represented in the flowchart or otherwise described herein, for example, may be considered as an ordered list of executable instructions for implementing logical functions, and may be embodied in any computer-readable medium for use by an instruction execution device, apparatus or device (such as a computer-based device, a device including a processor, or other device that can fetch instructions from an instruction execution device, apparatus or device and execute the instructions), or in conjunction with such instruction execution device, apparatus or device. For purposes of this specification, "computer-readable medium" may be any device that can contain, store, communicate, propagate or transmit a program for use by an instruction execution device, apparatus or device, or in conjunction with such instruction execution device, apparatus or device.

[0316] More specific examples of computer-readable media (a non-exhaustive list) include the following: an electrical connection with one or more wires (electronic device), a portable computer disk case (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disk read-only memory (CDROM). In addition, the computer-readable medium may even be a paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, deciphering or, if necessary, processing in another suitable manner, and then stored in a computer memory.

[0317] It should be understood that the various parts of the present invention can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, a plurality of steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution device. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0318] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "examples", "specific examples", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0319] Although the embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the claims and their equivalents.

[0320] The above is a specific description of the preferred implementation of the present invention, but the present invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without violating the spirit of the present invention. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present invention.

Claims

1. A method for dynamic synchronization of ship-shore narrowband network data, characterized in that: The following steps are involved: Acquire bitmap information of the first end and the second end; the bitmap information includes the bitmap position and synchronization status of all data blocks under each data group in the file to be synchronized; adjusting a sending window of the data packet according to a continuous state of 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 by the first end to the second end and a heartbeat request sent periodically; the feedback information includes historical reception feedback in response to the historical transmission data and a heartbeat reply in response to the heartbeat request; Based on the bitmap information, determining transmission data of the data packet through the sending window; Concurrently transmitting the transmission data of each of the data packets at the first end to the second end; obtaining reception feedback from the second end in response to the transmission data, and updating the bitmap information according to the reception feedback; Wherein, the transmission data is merged into the historical transmission data, and the reception feedback is merged into the historical reception 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 data synchronization of the file to be synchronized is completed.

2. The method for dynamic synchronization of ship-shore narrowband network data according to claim 1, characterized in that: The method further comprises the following steps: Splitting the to-be-synchronized file into a plurality of data blocks based on a preset transmission protocol, and then sequentially marking a block ID of each of the data blocks; Based on the preset group size, the corresponding data blocks are sequentially obtained from the to-be-synchronized file along the direction of the block ID from small to large to construct the data group, and then the group ID of each data group is sequentially marked; Performing 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; The bitmap position of each of the data blocks is determined based on the packet ID and the packet position.

3. The method for dynamic synchronization of ship-shore narrowband network data according to claim 1, characterized in that: The continuity state includes continuity and sequence number difference, and the continuity includes continuity or discontinuity; and adjusting the sending window of the data packet according to the continuity state of the interactive information between the first end and the second end includes the following steps: Acquire the latest data sent by the first end from the historical transmission data as target transmission data, and acquire the latest response data of the second end from the historical reception feedback as target reception feedback; The heartbeat request most recently sent by the first end is used as the target heartbeat request, and the heartbeat reply most recently responded by the second end is used as the target heartbeat reply; Determine a first continuous state according to the target transmission data and the Seq sequence number carried in the target reception feedback; the first continuous state includes a first continuity and a first sequence number difference; Determine a second continuous state according to the heartbeat request and the Seq sequence number carried by the heartbeat reply; the second continuous state includes a second continuity and a second sequence number difference; Based on the first continuous state or the second continuous state, a window size of the sending window is adjusted.

4. The method for dynamic synchronization of ship-shore narrowband network data according to claim 3, characterized in that: The adjusting the window size of the sending window based on the first continuous state or the second continuous state comprises at least one of the following steps: When the first continuity is continuous, the window size is expanded; otherwise, the first sequence number difference is determined; when the first sequence number difference is greater than a preset difference threshold, the window size is reduced, otherwise, the window size is not adjusted; When 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, and the reduction process includes halving reduction and step reduction; the expansion process and the reduction process are determined based on the window size before the sending window is adjusted.

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

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

7. The method for dynamic synchronization of ship-shore narrowband network data according to claim 1, characterized in that: The method further comprises at least one of the following steps: Acquire first verification information of the transmission data, verify and calculate first synchronization data of the second end in response to the transmission data to obtain second verification information; perform a first verification based on the first verification information and the second verification information; When the result of the first check is inconsistent, performing a first retransmission feedback to the first end; Acquire third verification information of the file to be synchronized, verify and calculate second synchronization data of the second end in response to completing synchronization of the file to be synchronized to obtain fourth verification information; perform a second verification based on the third verification information and the fourth verification information; When the result of the second check is inconsistent, a second retransmission feedback is performed to the first end.

8. A ship-shore narrowband network data dynamic synchronization device, characterized in that: include: The first module is used to obtain the bitmap information of the first end and the second end; The bitmap information includes the bitmap positions and synchronization states of all data blocks under each data group in the file to be synchronized; A second module, configured to adjust a sending window of the data packet according to a continuous state of 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 by the first end to the second end and a heartbeat request sent periodically; the feedback information includes historical reception feedback in response to the historical transmission data and a heartbeat reply in response to the heartbeat request; A third module is used to determine the transmission data of the data packet through the sending window based on the bitmap information; A fourth module, configured to concurrently transmit the transmission data of each of the data packets at the first end to the second end; A fifth module is configured to obtain reception feedback from the second end in response to the transmission data, and update the bitmap information according to the reception feedback; Wherein, the transmission data is merged into the historical transmission data, and the reception feedback is merged into the historical reception feedback; The sixth module is used to return to execute the second module until the data synchronization of the file to be synchronized is completed.

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

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

Images