Ship data receiving method, device, equipment and medium
By creating a synchronization status identifier and dynamic update mechanism in the ship data receiving system, combined with message queue and memory library management, the problem of incomplete synchronization status in ship-to-shore data transmission is solved, achieving atomic integrity of critical data and efficient resource utilization, thus ensuring navigation safety.
Patent Information
- Application Number
- CN202511060496.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-30
- Publication Date
- 2025-11-07
AI Technical Summary
Data transmission between ships and shore-based systems suffers from high communication costs, significant transmission delays, and poor connection stability. This can lead to incomplete synchronization during data reception between ships and shore, with critical data remaining in a semi-synchronous state after transmission interruptions, resulting in missing file data.
By creating and dynamically updating synchronization status identifiers for each file data, a synchronization credential for continuously tracking the integrity of the associated data chain is formed. Combined with message queue monitoring and memory library management, it ensures that the data maintains a visible and linked status in unreliable communication links, and accurately locates the file datasets that have not been synchronized after communication interruption is restored. It adopts a dual-channel satellite link design and virtual grid resource arbitration to prioritize the transmission of high-value data.
In unreliable communication environments, this ensures the atomic integrity of critical business data, eliminates semi-synchronous states, achieves finality in data transmission and efficient resource utilization, and avoids conflicts between communication resource scarcity and navigation safety.
Smart Images

Figure CN120915772A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present specification relates to the technical field of computer technology, and particularly relates to a ship data receiving method, device, equipment and medium. BACKGROUND
[0002] In the field of ship management, data transmission between the ship and the shore-based data center is a core link supporting ship state monitoring, navigation safety analysis and operation decision-making. Due to the particularity of the ship operation environment, the ship-shore communication has long relied on satellite links to realize remote data transmission, which has inherent defects such as high communication cost, significant transmission delay and poor connection stability.
[0003] Due to the above communication constraints, the existing technology may cause incomplete synchronization state management when receiving ship data, which may further cause key data to be in a semi-synchronous state after transmission interruption, that is, the business data has been received but the associated file data is missing. SUMMARY
[0004] One or more embodiments of the present specification provide a ship data receiving method, device, equipment and medium to solve the technical problems proposed in the background.
[0005] One or more embodiments of the present specification adopt the following technical solutions:
[0006] The ship data receiving method provided by one or more embodiments of the present specification comprises:
[0007] When receiving first business data sent by the ship, first file data associated with the first business data is retrieved;
[0008] If the first file data is not retrieved, first current synchronization record information of the first file data is created, the first current synchronization record information being in a synchronized state at the sending end and in an unsynchronized state at the receiving end;
[0009] If the first file data is received, the first current synchronization record information is changed to first latest synchronization record information, the first latest synchronization record information being in a synchronized state at both the sending end and the receiving end;
[0010] When receiving second file data of the ship, if synchronization record information related to the second file data is not retrieved, second current synchronization record information of the second file data is created, the second current synchronization record information being in a synchronized state at the sending end and in an unsynchronized state at the receiving end;
[0011] After receiving the second file data, the second current synchronization record information is changed to second latest synchronization record information, and the second latest synchronization record information is that the second file data is in a synchronized state at the sending end and the receiving end.
[0012] It should be noted that the application creates and dynamically updates the synchronization state identifier of the sending end and the receiving end for each file data, forms a synchronization voucher for continuously tracking the integrity of the associated data chain, so that the ship end business data and its associated file data maintain state linkage visibility during transmission across unreliable communication links, and when communication interruption is restored, the system can accurately locate the associated file data set that has not completed synchronization, thereby eliminating the half-synchronization state of missing associated files when business data has been received, and ensuring the atomicity and integrity of the data required for key business analysis.
[0013] Further, the first file data includes a plurality of file data, and the method further comprises:
[0014] checking whether all file data in the first file data are in a synchronized state at the sending end;
[0015] If yes, the version number of the receiving end is set to the same version number as the sending end, and the first business data sending completion information is returned to the sending end.
[0016] It should be noted that the application verifies the global synchronization state of the associated file cluster at the sending end at the receiving end, and uses the version number accurate alignment mechanism as the legal proof of full-link synchronization completion, so that the business data transmission integrity is transferred from isolated file level confirmation to new dimension of associated data set atomization completion, thereby injecting global verifiable terminal security for key business data flow in unreliable communication environment, and completely eliminating the business processing logic conflict caused by fragmented data state.
[0017] Further, the second file data of the receiving ship includes:
[0018] Listening to the message queue related to the file data, when receiving the instruction message of the second file data, saving the position information, file identifier and md5 value of the second file data in the message queue to the redis memory library.
[0019] It should be noted that the application implements three-element evidence solidification (message position / file identifier / MD5 value) of file data at the message queue listening level, converts transient communication events into reversible sequence traceable memory level snapshots, so that the easily perishable instruction state in high delay transmission environment obtains anti-interruption operation flexibility, thereby ensuring that the file transmission process has breakpoint resume precise positioning ability and integrity self-checking foundation when the communication link is interrupted.
[0020] Further, the method further comprises:
[0021] checking whether the sum of the number of the currently existing file data and the number of the file data being transmitted exceeds a preset number;
[0022] if not, allocating memory space for the file data being transmitted;
[0023] if yes, not allocating memory space for the file data being transmitted, and waiting for asynchronous processing.
[0024] It should be noted that the application converts the communication burst pressure into a controlled intermittent load process through the dynamic trade-off mechanism of the number of transmission files and the preset threshold value established in the memory resource scheduling layer, so that the limited memory resources always focus on the file transmission window that can be carried, thereby building an operation baseline to prevent overload collapse in the environment of scarce satellite link resources, and ensuring the self-stable throughput resilience of the data transmission system in the high fluctuation business scenario.
[0025] Further, the method further comprises:
[0026] During the navigation of the ship, the motion characteristic parameters of the ship are collected in real time, including the roll angular velocity change rate, the speed mutation rate and the ship attitude angle;
[0027] if the change rate of the motion characteristic parameters exceeds the preset threshold value, it is determined that the ship enters a dangerous working condition state;
[0028] According to the preset data value grading matrix, the safety weight and time efficiency coefficient of the current to-be-transmitted business data and file data are dynamically scored, and the data type with a score higher than a threshold value is marked as a high priority label;
[0029] Through the satellite link double-channel design, the high-priority label data is allocated to the high-priority channel for real-time transmission, and the remaining data is allocated to the low-priority channel for asynchronous transmission.
[0030] It should be noted that the application forms a dangerous working condition intelligent discrimination mechanism by coupling the ship motion attitude perception and the data value dynamic evaluation system, so that the satellite communication channel resources can implement autonomous strategic selection of data flow based on the navigation risk level, thereby building a high-value key data priority breakthrough channel in the critical state of the ship safety operation boundary, ensuring that the fatal data (such as collision avoidance instructions and mechanical fault alarms) affecting the navigation safety can obtain unblocked transmission right under the constraint of physical link resources, and finally achieving the adaptability of the communication resource scarcity and the navigation safety guarantee demand.
[0031] Further, if the change rate of the motion characteristic parameters does not exceed the preset threshold value, the method further comprises:
[0032] The bandwidth resource occupied by the high-priority channel is automatically released.
[0033] It should be noted that the bandwidth resource control node after the dangerous working condition is released, the priority channel system evolves from a one-way preemption mode to a two-way elastic potential matching architecture, and the idle communication potential in the over-protected state is quickly converted into normal data transmission kinetic energy, thereby building a dynamic balance hub between navigation safety monitoring and communication resource efficiency, ensuring that the scarce satellite link resources are never solidified in the unnecessary high-priority occupation state, and achieving a resource energy efficiency cycle of the ship-shore communication system based on the physical state of the ship.
[0034] Further, the method further comprises:
[0035] The port area is divided into virtual grids of a preset size based on position information, and each virtual grid is assigned an independent red lock instance;
[0036] When the specified ship enters a target virtual grid, a regional lock application request is initiated to the red lock instance corresponding to the target virtual grid;
[0037] If the application is successful, the data transmission channel is activated, and the current to-be-transmitted service data and file data in the specified ship are transmitted.
[0038] It should be noted that the spatial topology of the virtual grid is decoupled and bound with the resource arbitration of the red lock instance, the physical sea area collision hotspot area is converted into a discrete self-consistent communication unit, so that multiple ships obtain accurate location service contracts when competing for communication resources in a limited space, thereby building an isolated transmission channel to prevent channel aliasing in the conflict-prone area near the port, ensuring that single-ship data transmission obtains a deterministic network path while completely avoiding systematic communication collapse caused by multi-ship signal same-frequency mutual exclusion.
[0039] One or more embodiments of the present specification provide a ship data receiving device, comprising:
[0040] The retrieval unit retrieves first file data associated with the first service data when receiving the first service data sent by the ship;
[0041] The first creation unit creates first current synchronization record information of the first file data if the first file data is not retrieved, the first current synchronization record information being in a synchronized state at the sending end and an unsynchronized state at the receiving end.
[0042] a first changing unit, if the first file data is received, changing the first current synchronization record information into first latest synchronization record information, the first latest synchronization record information being that the first file data is in a synchronized state at both the sending end and the receiving end;
[0043] a second creating unit, when second file data of the ship is received, if the synchronization record information related to the second file data is not searched, creating second current synchronization record information of the second file data, the second current synchronization record information being that the second file data is in a synchronized state at the sending end and in an unsynchronized state at the receiving end;
[0044] a second changing unit, after the second file data is received, changing the second current synchronization record information into second latest synchronization record information, the second latest synchronization record information being that the second file data is in a synchronized state at both the sending end and the receiving end.
[0045] One or more embodiments of the present specification provide a ship data receiving device, comprising:
[0046] at least one processor; and,
[0047] a memory in communication connection with the at least one processor; wherein,
[0048] the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to:
[0049] when first service data sent by the ship is received, searching first file data associated with the first service data;
[0050] if the first file data is not searched, creating first current synchronization record information of the first file data, the first current synchronization record information being that the first file data is in a synchronized state at the sending end and in an unsynchronized state at the receiving end;
[0051] if the first file data is received, changing the first current synchronization record information into first latest synchronization record information, the first latest synchronization record information being that the first file data is in a synchronized state at both the sending end and the receiving end;
[0052] when second file data of the ship is received, if the synchronization record information related to the second file data is not searched, creating second current synchronization record information of the second file data, the second current synchronization record information being that the second file data is in a synchronized state at the sending end and in an unsynchronized state at the receiving end;
[0053] After receiving the second file data, the second current synchronization record information is changed into second latest synchronization record information, and the second latest synchronization record information is that the second file data is in a synchronized state at both the sending end and the receiving end.
[0054] The one or more embodiments of the present specification provide a nonvolatile computer storage medium, which stores computer executable instructions, and the computer executable instructions can realize the following when executed by a computer:
[0055] When receiving the first service data sent by the ship, the first file data associated with the first service data is searched;
[0056] If the first file data is not searched, first current synchronization record information of the first file data is created, the first current synchronization record information is that the first file data is in a synchronized state at the sending end and is in an unsynchronized state at the receiving end;
[0057] If the first file data is received, the first current synchronization record information is changed into first latest synchronization record information, and the first latest synchronization record information is that the first file data is in a synchronized state at both the sending end and the receiving end;
[0058] When receiving the second file data of the ship, if the synchronization record information related to the second file data is not searched, second current synchronization record information of the second file data is created, and the second current synchronization record information is that the second file data is in a synchronized state at the sending end and is in an unsynchronized state at the receiving end;
[0059] After receiving the second file data, the second current synchronization record information is changed into second latest synchronization record information, and the second latest synchronization record information is that the second file data is in a synchronized state at both the sending end and the receiving end.
[0060] The above at least one technical solution adopted by the embodiments of the present specification can achieve the following beneficial effects:
[0061] The present application creates and dynamically updates the synchronization state identification of the sending end and the receiving end for each file data, forms a synchronization voucher for continuously tracking the integrity of the associated data chain, and makes the ship service data and its associated file data keep state linkage visible during the transmission process across the unreliable communication link. When the communication interruption is restored, the system can accurately locate the associated file data set that has not completed synchronization, so as to eliminate the half-synchronization state of the missing associated file data while the service data has been received, and ensure the data atomicity and integrity required for key business analysis. BRIEF DESCRIPTION OF DRAWINGS
[0062] In order to make the technical solutions in the description embodiments or prior art clearer, the drawings needed to be used in the description embodiments or prior art description will be briefly introduced as follows. Obviously, the drawings described below are only some embodiments described in the description, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.
[0063] Figure 1 A flowchart of a ship-shore data transmission and reception method provided for one or more embodiments of the description;
[0064] Figure 2 A flowchart of a transmission file provided for one or more embodiments of the description;
[0065] Figure 3 A flowchart of a ship data reception method provided for one or more embodiments of the description;
[0066] Figure 4 A structural diagram of a ship data reception device provided for one or more embodiments of the description;
[0067] Figure 5 A structural diagram of a ship data reception device provided for one or more embodiments of the description. DETAILED DESCRIPTION
[0068] The description embodiments provide a ship data reception method, device, equipment and medium.
[0069] In order to make those skilled in the art better understand the technical solutions in the description, the technical solutions in the description embodiments will be clearly and completely described below in combination with the drawings in the description embodiments. Obviously, the described embodiments are only some of the embodiments of the description, not all the embodiments. Based on the description embodiments, all other embodiments obtained by those skilled in the art without creative labor should be within the protection scope of the description.
[0070] In ship management, because of high communication cost, high delay, low bandwidth and instability between the ship and the shore, servers are respectively set up on the ship and the shore to run independently. In actual management, various business data such as inspection reports, purchase application forms, exercise scheme reports and maintenance work orders need to be transmitted between the ship and the shore, and some of these business data have multiple attachments.
[0071] Taking an inspection report as an example, after the shore-side manager inspects the ship and fills in the report and takes photos of defects, the report is uploaded to the system on the shore side, and the system needs to transmit data to the corresponding ship, and the person in charge on the ship also needs to take photos and fill in the corresponding report work order after repairing the defects and upload it to the ship-side system, and the system returns the repair result to the shore side.
[0072] In this process, the ship-side and shore-side systems need to ensure that business data and files are accurately delivered and recorded, avoiding repeated sending in subsequent synchronization. Because the system manages many ships, there may be a scenario where multiple ships send data to the shore-side system at the same time, causing a large pressure on the shore-side service. The sender needs to obtain confirmation information from the receiver to determine the current version of the receiver.
[0073] There are many similar scenarios in ship management, and a unified method is proposed to ensure accurate delivery of data and files and to facilitate the expansion of each business module for ship-shore data interaction.
[0074] The present application provides a ship-shore data sending and receiving method, which uses mqtt to ensure that messages can be delivered in weak network environment, uses message queue to receive data from multiple ships to avoid accumulation, deploys distributed services on the shore side, adopts double-channel consumption of message queue messages, and combines distributed locks to ensure that large files can be correctly and orderly received and saved, and ensures the consumption order and service availability when receiving large files.
[0075] The overall process of sending data is as follows, which can be seen in Figure 1 The flowchart of the ship-shore data sending and receiving method is shown in the figure:
[0076] 1. A unified sending object dto is provided for sending messages, and the following contents need to be written into the dto when the business module is called, including:
[0077] a) Business code, corresponding to the receiving end, used to identify the type of business, and the receiving end uses the code to distribute to the processor of the corresponding business;
[0078] b) Target ship code, indicating which ships the data is sent to;
[0079] c) Unique code of the business data itself, used for version control;
[0080] d) Unique code of the file associated with the business data and uploaded to the sending end file service;
[0081] 2. A unified sending method is provided, and the method is called after the dto is filled in;
[0082] 3. Sending preparation stage, the system automatically retrieves the version information of the sending end and receiving end of the current service data, without the need for new development. The version number of service data is incremented by 1;
[0083] a) If not found, create a new version information, the sending end version is set to 1, and the receiving end is set to 0;
[0084] b) If found, add 1 to the sending end version, and the receiving end remains unchanged.
[0085] 4. Automatically write version information into dto, and send service data to mqtt service.
[0086] 5. The system retrieves the sending end and receiving end file version in the version information according to the file name filled in by the user in the dto. The file version number has only two states: synchronized and unsynchronized;
[0087] a) If not found, create the sending end and receiving end version information, set the sending end to synchronized, and the receiving end to unsynchronized. The file needs to be transmitted;
[0088] b) If found, the state of the receiving end is synchronized, which means that the file has been transmitted before and does not need to be sent.
[0089] 6. The system sends the sending end to the file service to obtain the file that needs to be sent, and transmits it through mqtt.
[0090] 7. Because there may be multiple ships transmitting data at the same time, the shore uses kafka to receive messages, and then consumes the messages in kafka to achieve the effect of peak cutting, avoiding the problem of not processing in time due to too large instantaneous data volume. At the same time, after the message is written into kafka, it will be saved on the hard disk, realizing persistence, so that even if the receiving end has system exceptions, the message can be retrieved within a certain time.
[0091] 8. The receiving end consumes the messages under the kafka service data topic to obtain service data and transmits them to the distributor. The distributor distributes the messages to the specific business processing object according to the business code in the dto.
[0092] a) The business processing object of the receiving end inherits the unified base class, and the specific business needs to develop corresponding functions. Only the processing of business data needs to be customized, and the rest of the work is completed by the public base class.
[0093] b) After the receiving end processes the service data, it will retrieve the version information in its own service, set the sending end version to the sending end version in the dto, and retrieve the corresponding file synchronization state.
[0094] i. If a certain file is not found, create a record for the file, set the sending end to synchronized, and the receiving end to unsynchronized.
[0095] ii. If the file synchronization information is retrieved and both the sending end and the receiving end are synchronized, it means that the file transmission is completed. If all files have completed synchronization, the receiving end version is set to be the same as the sending end, and a synchronization completion message is returned to the sending end.
[0096] iii. Delay the re-checking of the file synchronization state to avoid the situation where the transmission of business data is completed while the file is also completed, and the completion message is not returned to the sending end.
[0097] 9. The receiving end consumes the messages under the kafka file topic to obtain the file content, and uploads it to the file server of the receiving end. The process is automatically completed by the system without secondary development. The reliability of file transmission is guaranteed by the receiving end, which will be introduced later.
[0098] a) The receiving end receives the file and retrieves the version according to the unique file code
[0099] i. If no record is found, it means that the file arrives before the business data. The version information of the sending end and the receiving end is created, and the sending end is set to be synchronized, and the receiving end is set to be unsynchronized.
[0100] ii. If the record is found and the receiving end is synchronized, it means that the repeated message is received, and no processing is done.
[0101] b) When the above step receives an unsynchronized file, the file is uploaded to the file server, and then the file version of the receiving end is set to be synchronized, and the file transmission completion information is fed back to the sending end.
[0102] c) Check all file versions associated with the business data. If all receiving ends of the files are synchronized, it means that all associated files have completed transmission. The receiving end business version is set to be the same as the version number of the sending end, and the business data sending completion message is returned to the sending end.
[0103] 10. When the sending end receives the file synchronization completion message, the file version of the receiving end is set to be synchronized. When the receiving end business data completes synchronization, the receiving end business version is set to be the same as the sending end, and all associated file versions of the receiving end are set to be synchronized.
[0104] 11. The sending end checks the version information regularly, and retransmits the content that is not completed within the timeout.
[0105] The specific file transmission process is as follows, see Figure 2 the transmission file flowchart shown in the figure:
[0106] 1, The sending end calculates the md5 value for verification, sends the initialization message through mqtt, uses the file sending topic prefix + file md5 as the topic, and sends the content including the file unique id, file size, and message type (init);
[0107] 2, The sending end divides the file into file blocks of a preset size, sends them in the form of byte array, and sends each file block in turn, with the first four bits as the file block number;
[0108] 3, When all file blocks are sent, send the file end message, the message content is the same as the initialization message, and the message type is end sending (fin)
[0109] 4, The receiving end forwards the message to the message queue kafka, adds the message type, message source, and file id to the message header of kafka, and uses the file id as the key to ensure that the messages of the same file are in order.
[0110] 5, The receiving end listens to the message queue, and when it receives a message with the type "initialization", it saves the message's position information, file id, and md5 value in the redis memory database, and sets the file status to "initialization".
[0111] 6, The receiving end checks the number of files that have already existed and are being transmitted, and if it does not exceed the preset number, it allocates memory space, prepares to cache the file, and sets the file status to "transmitting"; if it exceeds the preset number, it does not process to avoid memory overflow, and waits for asynchronous processing;
[0112] 7, When receiving a message with the type "file block", check if there is a cache of the file in the memory space
[0113] a) If found, it means that it is received in a synchronous manner, compare the cached file block number and the received number, if the difference between the two is 1, it means that the file block is received in the correct order, update the cached number to the latest received number, and add the received file block to the memory; If the serial number is incorrect, it may appear multiple transmissions or message loss in extreme cases, wait for the end message to be received and then process;
[0114] b) If not found, it means that the synchronous transmission file has reached the maximum number, and waits for asynchronous processing;
[0115] 8, When receiving a message with the type "end sending", find the file information in redis:
[0116] a) If not found, it means a very small probability of message loss, send a retransmission request to the sending end;
[0117] b) If the end message is found first, save the position information in the message queue to redis, so that even if the file saving function is down during processing, other nodes in the cluster can complete the file reception in an asynchronous manner.
[0118] c) When the receiving end receives the file information, check whether the corresponding file block is saved in the memory. If it can be found, it indicates that the file is transmitted in a synchronous manner. Check the file md5 check value. If it passes, use redis to add a distributed lock to the file id and prepare to upload to the file server. If it does not pass, it indicates that there is a small probability of data error, and the sender is requested to resend.
[0119] d) If the receiving end memory cannot find the file information, it means that it needs to be transmitted in an asynchronous manner. At this time, try to get a thread from the preset thread pool. If the number of threads currently being processed exceeds the upper limit of the thread pool, do not process to avoid memory overflow. If the number of threads does not exceed the maximum number of threads, get a thread to operate. According to the start and end positions of the file in the message queue found in the redis memory database, consume the messages in this section again to obtain the file content. After successful acquisition, the file md5 check value is checked. If it passes, the file id is locked and the file server is prepared for uploading.
[0120] e) Before uploading the file to the file server, check whether the file exists according to the file id. If it does not exist, upload it. After successful uploading, release the lock of the file id, and then delete the cache information in redis and the memory. If it already exists, do not perform the uploading operation, and directly release the corresponding lock and cache.
[0121] f) Query whether there is a file information that has been transmitted but not uploaded in the redis memory database. If it exists, use the asynchronous receiving method to receive and process the file.
[0122] When the ship end sends the file to the shore end, the following beneficial effects are achieved:
[0123] 1. MQTT is used to ensure that messages are not lost. Even if they are lost, there is a retransmission scheme to ensure that the final result is correct.
[0124] 2. Segment transmission of files to avoid large message sending failure and improve sending efficiency and success rate in weak network environment.
[0125] 3. Use the message queue kafka to receive messages. File information is persisted on the message queue server within a specified time.
[0126] 4. When there are idle resources in the receiving end program, cache and splice part of the file block, and upload it to the file server after splicing is completed.
[0127] 5. When resources are scarce at the receiving end, record the file's position in the message queue, and then retrieve the file information from the corresponding position for reception when resources are plentiful;
[0128] 6. The receiving end is a distributed cluster, and file transfer must be guaranteed not to be lost even if any node fails at any time.
[0129] Figure 3 This diagram illustrates a process for a ship data receiving method provided in one or more embodiments of this specification. This process can be executed by the receiving server of a ship data receiving system. Certain input parameters or intermediate results in the process can be manually adjusted to help improve accuracy.
[0130] The method flow steps of the embodiments in this specification are as follows:
[0131] S301, when receiving the first business data sent by the ship, retrieve the first file data associated with the first business data.
[0132] In embodiment S301 of this specification, when the receiving server captures the first service data message sent by the ship, it immediately parses the metadata identifier of the service data; based on the identifier, it queries the associated file index table of the local database to retrieve whether there is a first file data storage record bound to the service data.
[0133] S302, if the first file data is not found, then create the first current synchronization record information of the first file data. The first current synchronization record information indicates that the first file data is in a synchronized state at the sending end and in an unsynchronized state at the receiving end.
[0134] In embodiment S302 of this specification, when the associated file index table does not return a valid record, a synchronization state initialization operation is performed, that is, a new synchronization record entry is created in the synchronization record database as the first current synchronization record information of the first file data, and the status attributes of the record are set: the sending end status field is marked as "synchronized state" (indicating that the ship-side file is ready); the receiving end status field is marked as "unsynchronized state" (indicating that the shore-based system has not yet received the file).
[0135] S303, if the first file data is received, the first current synchronization record information is changed to the first latest synchronization record information, where the first latest synchronization record information indicates that the first file data is synchronized at both the sending end and the receiving end.
[0136] In the embodiment S303 of the present application, when the file transmission service successfully receives the complete first file data, the created first current synchronization record information is located by the unique identifier of the file data. A state double confirmation update is performed: the original receiving end state is changed from "unsynchronized state" to "synchronized state"; and the updated record is defined as the first latest synchronization record information (both end states are "synchronized state").
[0137] In the embodiment S304 of the present application, when the second file data of the receiving ship is received, if the synchronization record information related to the second file data is not searched, the second current synchronization record information of the second file data is created, and the second current synchronization record information is in the synchronized state at the sending end and in the unsynchronized state at the receiving end.
[0138] In the embodiment S304 of the present application, when the second file data of the receiving ship is received, if the synchronization record information related to the second file data is not searched, the second current synchronization record information of the second file data is created, and the second current synchronization record information is in the synchronized state at the sending end and in the unsynchronized state at the receiving end.
[0139] In the embodiment S305 of the present application, after the second file data is completely received and verified, the corresponding second current synchronization record information can be tracked according to the transmission log, and the global state synchronization operation is performed: the receiving end state of the record is updated to "synchronized state"; and the second latest synchronization record information (both end states are "synchronized state") is finally formed.
[0140] In the embodiment S305 of the present application, after the second file data is completely received and verified, the corresponding second current synchronization record information can be tracked according to the transmission log, and the global state synchronization operation is performed: the receiving end state of the record is updated to "synchronized state"; and the second latest synchronization record information (both end states are "synchronized state") is finally formed.
[0141] It should be noted that, by creating and dynamically updating the synchronization state identifiers of the sending end and the receiving end for each file data, the present application forms the synchronization credentials for continuously tracking the completeness of the associated data chain, so that the state linkage of the ship end business data and the associated file data in the transmission process across the unreliable communication link is kept visible, and when the communication interruption is restored, the system can accurately locate the associated file data set that is not synchronized, thereby eliminating the half-synchronized state of the associated file missing while the business data is received, and ensuring the data atomicity and completeness required for key business analysis.
[0142] Further, the first file data can contain multiple file data, and whether all the file data in the first file data is in a synchronized state at the sending end is checked; if yes, the version number of the receiving end is set to be the same as the version number of the sending end, and the first service data sending completion information is returned to the sending end.
[0143] It should be noted that for the above, the following specific implementation can be used:
[0144] File cluster state scanning: extract all file data identification lists (such as image files 001-005) contained in the first file data. Traverse the synchronization record information of each file in the list, and check whether the sending end state field of each file is in the "synchronized state".
[0145] Version synchronization condition triggering: when the above check result is that all files are in the synchronized state at the sending end:
[0146] a. read the current effective global version number of the sending end (such as V3.2.1);
[0147] b. update the corresponding version number stored in the receiving end to the value.
[0148] Final state confirmation instruction return: based on the successfully executed version number alignment operation, generate the first service data sending completion information message; and transmit the message to the ship sending end through the satellite communication channel.
[0149] It should be noted that the present application verifies the global synchronization state of the associated file cluster at the sending end at the receiving end, and uses the version number accurate alignment mechanism as the legal proof of the completion of the full-link synchronization, so that the business data transmission integrity is transferred from the isolated file level confirmation to the new dimension of the atomic completion of the associated data set, thereby injecting the global verifiable finality guarantee for the key business data flow in the unreliable communication environment, and completely eliminating the business processing logic conflict caused by the fragmented data state.
[0150] Further, when the second file data of the receiving ship is received, the message queue related to the file data can be listened to, and when the instruction message of the second file data is received, the position information, file identification and md5 value of the second file data in the message queue are saved to the redis memory library.
[0151] It should be noted that for the above, the following specific implementation can be used:
[0152] Event-driven start: deploy a message queue listening service (such as RabbitMQ consumer) at the receiving end; when the instruction message of the second file data appears in the message queue, the collection process is automatically triggered.
[0153] Key metadata solidification: three elements are extracted from the instruction message, as follows:
[0154] a. Position information: the physical offset of the message in the queue (such as Kafka partition offset);
[0155] b. File identification: the unique code of the second file data (such as UUIDv4 format);
[0156] c. MD5 value: the hash digest value (128-bit check code) of the file content.
[0157] Memory library persistence processing: construct the following Redis storage key-value pair:
[0158] Key: composite key generated by splicing file identification and position information (example: FileID: Offset);
[0159] Value: can use the hash structure of redis to store.
[0160] It should be noted that the application implements three-element evidence solidification (message position / file identification / MD5 value) on the file data at the message queue monitoring level, converts the instantaneous communication event into a reversible sequence traceable memory-level snapshot, so that the easily perishable instruction state in the high-latency transmission environment obtains the anti-interrupt operation resilience, thereby ensuring that the file transmission process has the precise positioning ability and integrity self-checking foundation of breakpoint resume when the communication link flashes.
[0161] Further, the embodiment of the present specification can also check whether the sum of the number of existing file data and the number of file data being transmitted exceeds the preset number; if not, allocate memory space for the file data being transmitted; if yes, do not allocate memory space for the file data being transmitted, and wait for asynchronous processing.
[0162] It should be noted that for the above content, the following specific implementation scheme can be used:
[0163] Resource total amount verification: the sum of the following two key indicators is counted:
[0164] a. The number of existing file data that has been persisted and stored;
[0165] b. The number of file data being transmitted in the communication channel.
[0166] Threshold comparison and shunting:
[0167] For the non-overrun processing path: if the total amount of files ≤ the preset number, immediately allocate memory space for the file data being transmitted, and start the transmission process.
[0168] For the out-of-limit processing path: if the total amount of files > the preset amount, suspend the memory allocation request of the current file data, and move it to the asynchronous to-be-processed queue to wait for resource release.
[0169] Standby state maintenance: periodic inspection is performed on the file data moved to the asynchronous queue:
[0170] a. The total amount of resources is verified again every fixed time interval in step 1;
[0171] b. When the condition "total amount ≤ preset amount" is met, activate memory allocation.
[0172] It should be noted that the application establishes a dynamic trade-off mechanism between the number of transmission files and the preset threshold in the memory resource scheduling layer, converts the communication burst pressure into a controlled intermittent load process, and focuses the limited memory resources on the file transmission window that can be carried, thereby building an operation baseline to prevent overload collapse in a satellite link resource scarce environment, and ensuring that the data transmission system maintains self-stable throughput resilience in a high fluctuation business scenario.
[0173] Further, during the ship sailing process, the motion characteristic parameters of the ship can be collected in real time, including the roll angular velocity change rate, the speed mutation rate and the ship attitude angle; if the change rate of the motion characteristic parameters exceeds the preset threshold, it is determined that the ship enters a dangerous working condition state; according to the preset data value grading matrix, the safety weight and the time efficiency coefficient of the current to-be-transmitted business data and file data are dynamically scored, and the data type with a score higher than the threshold is marked as a high priority label; through the satellite link double-channel design, the high priority label data is allocated to the high priority channel for real-time transmission, and the remaining data is allocated to the low priority channel for asynchronous transmission.
[0174] It should be noted that for the above content, the following specific implementation scheme can be used:
[0175] Multi-source sensing data capture, continuously collecting the following data through the shipborne inertial measurement unit:
[0176] Roll angular velocity change rate (angular velocity differential value per unit time);
[0177] Speed mutation rate (absolute value of speed change per unit time);
[0178] Ship attitude angle (pitch / roll / yaw three-axis angle);
[0179] The data sampling interval meets the requirements of maritime safety standards (such as 200 ms / time).
[0180] Dynamic threshold out-of-bound detection, real-time calculation of current motion parameter change rate instantaneous value: change rate = | current sampling value - previous sampling value | / sampling time interval;
[0181] When any parameter change rate exceeds the preset threshold, the "dangerous working condition state" judgment mark can be activated to trigger the priority decision-making process.
[0182] Value classification matrix application, load preset data value classification matrix (including two-dimensional evaluation axis):
[0183] Safety weight coefficient: ship risk level (1-10) caused by data failure;
[0184] Time coefficient: maximum transmission delay level (1-10) allowed by data;
[0185] Perform matrix operation on the current to-be-transmitted business data and file data:
[0186] Priority score = safety weight x time coefficient, and label data entities with a score higher than the set threshold with a high priority label.
[0187] Satellite link shunting execution, configure satellite communication double physical channel:
[0188] High priority channel: exclusive real-time transmission bandwidth resource;
[0189] Low priority channel: shared asynchronous transmission bandwidth pool.
[0190] Implement data flow classification guide: force route high priority labeled data to high priority channel; the rest of the data → default allocation to low priority channel queue.
[0191] It should be noted that the application forms a dangerous working condition intelligent discrimination mechanism by coupling ship motion posture perception and data value dynamic evaluation system, so that satellite communication channel resources can implement autonomous strategic selection of data flow based on sailing risk level, thereby constructing a high-value key data priority breakthrough channel in the critical state of ship safety operation boundary, ensuring that the fatal data (such as collision avoidance instructions, mechanical fault alarms) affecting sailing safety can obtain unblocked transmission right under the constraint of physical link resources, and finally achieve the adaptability of communication resource scarcity and sailing safety guarantee demand.
[0192] Further, if it is detected that the change rate of the motion characteristic parameter does not exceed the preset threshold, the bandwidth resources occupied by the high priority channel can be automatically released.
[0193] It should be noted that for the above content, the following specific implementation scheme can be used:
[0194] Continuous motion parameter monitoring: maintain real-time acquisition of ship motion characteristic parameters (roll angular velocity change rate / speed sudden change rate / ship attitude angle); calculate the dynamic difference between the current parameter change rate and the preset threshold value.
[0195] Threshold value out-of-range removal detection, when the change rates of all motion characteristic parameters do not exceed the preset threshold value in the next 3 sampling periods (to avoid misjudgment due to transient fluctuations).
[0196] Trigger safety state conversion instruction:
[0197] Remove the "dangerous working condition state" mark and activate the bandwidth release process.
[0198] Bandwidth dynamic release operation, resource reallocation is performed on the satellite link dual-channel system:
[0199] a. High priority channel: automatically release the non-active bandwidth currently occupied (the part not used by high priority data) to the public resource pool;
[0200] b. Low priority channel: immediately take over the released bandwidth resources and improve the asynchronous transmission queue processing rate.
[0201] It should be noted that the bandwidth resource automatic release control node after the dangerous working condition is removed, which makes the priority channel system evolve from a one-way preemption mode to a two-way elastic potential matching architecture, quickly converts the idle communication potential in the over-protection state into normal data transmission kinetic energy, thereby building a dynamic balance hub between navigation safety monitoring and communication resource efficiency, ensuring that scarce satellite link resources are never solidified in unnecessary high priority occupation state, achieving adaptive resource energy efficiency cycle of ship-shore communication system based on ship physical state.
[0202] Further, the present application can divide the port area into virtual grids of a preset size based on position information, and each virtual grid is assigned an independent red lock instance; when a specified ship enters a target virtual grid, a regional lock application request is initiated to the red lock instance corresponding to the target virtual grid; if the application is successful, the data transmission channel is activated, and the current to-be-transmitted service data and file data in the specified ship are transmitted.
[0203] It should be noted that for the above content, the following specific implementation scheme can be used:
[0204] Geospatial discretization processing: import the electronic chart boundary coordinates of the target port, cut the port sea area into units of a preset size (such as 500m x 500m), and generate a virtual grid topology matrix covering the entire port (each grid is assigned a unique ID).
[0205] Grid resource independent allocation: create a dedicated red lock instance for each virtual grid, and the red lock instance storage structure:
[0206] {
[0207] "grid_id":"G101",
[0208] "lock_status":"unlocked", / / Initial state is unlocked
[0209] "current_ship":null / / Identifier for occupied ship
[0210] }
[0211] Dynamic location matching trigger: The AIS location signal (latitude and longitude coordinates) of the specified vessel is received in real time, and the target virtual grid ID of the vessel is calculated through the grid topology matrix, triggering the area lock application process.
[0212] Exclusive resource request operation: Send a request to the red-lock instance of the target virtual mesh; Red-lock instance checks status:
[0213] If lock_status is "unlocked": immediately update to "locked" and record the vessel identifier, then return a successful application status code;
[0214] If "locked": Returns a request failure response (with information on the current occupant).
[0215] Communication resource binding execution: After receiving the application success status code:
[0216] a. Activate the ship's dedicated data transmission channel;
[0217] b. Scan the ship's queue of pending data transmissions;
[0218] c. Inject business data and file data into the channel for transmission.
[0219] It should be noted that this invention transforms physical sea area collision hotspots into discretized self-consistent communication units by decoupling the spatial topology of the virtual grid and binding the resource arbitration of the red lock instance. This enables multiple ships to obtain accurate location service contracts when competing for communication resources in a limited space, thereby constructing an isolated transmission channel to prevent channel aliasing in the high-conflict zone near the port. This ensures that single-ship data transmission obtains a deterministic network path while completely avoiding systemic communication collapse caused by the mutual exclusion of signals from multiple ships on the same frequency.
[0220] Figure 4 A schematic diagram of a ship data receiving device provided for one or more embodiments of this specification includes: a retrieval unit 401, a first creation unit 402, a first modification unit 403, a second creation unit 404, and a second modification unit 405.
[0221] The retrieval unit 401 retrieves first file data associated with the first service data when receiving the first service data sent by the ship;
[0222] The first creation unit 402 creates first current synchronization record information of the first file data if the first file data is not retrieved, the first current synchronization record information being in a synchronized state at the sending end and in an unsynchronized state at the receiving end;
[0223] The first change unit 403 changes the first current synchronization record information into first latest synchronization record information if the first file data is received, the first latest synchronization record information being in a synchronized state at both the sending end and the receiving end;
[0224] The second creation unit 404 creates second current synchronization record information of the second file data if the second file data related synchronization record information is not retrieved when receiving the second file data sent by the ship, the second current synchronization record information being in a synchronized state at the sending end and in an unsynchronized state at the receiving end;
[0225] The second change unit 405 changes the second current synchronization record information into second latest synchronization record information after receiving the second file data, the second latest synchronization record information being in a synchronized state at both the sending end and the receiving end.
[0226] Figure 5 A structural schematic diagram of a ship data receiving device provided for one or more embodiments of the present specification comprises:
[0227] at least one processor; and,
[0228] a memory in communication connection with the at least one processor; wherein,
[0229] the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to:
[0230] retrieve first file data associated with the first service data when receiving the first service data sent by the ship;
[0231] create first current synchronization record information of the first file data if the first file data is not retrieved, the first current synchronization record information being in a synchronized state at the sending end and in an unsynchronized state at the receiving end;
[0232] If the first file data is received, the first current synchronization record information is changed to first latest synchronization record information, and the first latest synchronization record information indicates that the first file data is synchronized in both the sending end and the receiving end;
[0233] When the second file data of the receiving ship is received, if the synchronization record information related to the second file data is not searched, second current synchronization record information of the second file data is created, and the second current synchronization record information indicates that the second file data is synchronized in the sending end and is not synchronized in the receiving end;
[0234] After the second file data is received, the second current synchronization record information is changed to second latest synchronization record information, and the second latest synchronization record information indicates that the second file data is synchronized in both the sending end and the receiving end.
[0235] One or more embodiments of the present specification provide a non-volatile computer storage medium, which stores computer executable instructions, and the computer executable instructions can realize the following when executed by a computer:
[0236] When the first service data sent by the receiving ship is received, first file data associated with the first service data is searched;
[0237] If the first file data is not searched, first current synchronization record information of the first file data is created, and the first current synchronization record information indicates that the first file data is synchronized in the sending end and is not synchronized in the receiving end;
[0238] If the first file data is received, the first current synchronization record information is changed to first latest synchronization record information, and the first latest synchronization record information indicates that the first file data is synchronized in both the sending end and the receiving end;
[0239] When the second file data of the receiving ship is received, if the synchronization record information related to the second file data is not searched, second current synchronization record information of the second file data is created, and the second current synchronization record information indicates that the second file data is synchronized in the sending end and is not synchronized in the receiving end;
[0240] After the second file data is received, the second current synchronization record information is changed to second latest synchronization record information, and the second latest synchronization record information indicates that the second file data is synchronized in both the sending end and the receiving end.
[0241] Each of the embodiments in the present specification is described in a progressive manner, and the same or similar parts among the embodiments can be mutually referred to. Each of the embodiments focuses on the difference from other embodiments. In particular, for the apparatus, device, and non-transitory computer storage medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the part of the method embodiments.
[0242] Each of the embodiments in the present specification is described in a progressive manner, and the same or similar parts among the embodiments can be mutually referred to. Each of the embodiments focuses on the difference from other embodiments. In particular, for the apparatus, device, and non-transitory computer storage medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the part of the method embodiments.
[0243] Those skilled in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized in electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.
[0244] In the embodiments provided in the present application, it should be understood that the disclosed apparatus / network device and method can be implemented in other ways. For example, the apparatus / network device embodiments described above are only schematic. The division of the modules or units is only a logical function division, and there can be another division manner in actual implementation. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or in other forms.
[0245] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., they can be located in one place, or distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiments.
[0246] In addition, each functional unit in each of the embodiments of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The above-mentioned units can be realized in the form of hardware or software.
[0247] The integrated module / unit, if implemented in the form of a software functional unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the above-mentioned embodiment methods can also be completed by a computer program instructing related hardware, and the computer program can be stored in a computer readable storage medium. When the computer program is executed by a processor, the steps of the above-mentioned various method embodiments can be implemented. The computer program includes computer program code, which can be in the form of source code, object code, executable file or some intermediate form. The computer readable medium can include any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content included in the computer readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction, for example, in some jurisdictions, according to legislation and patent practice, the computer readable medium does not include electrical carrier signals and telecommunication signals.
[0248] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.
Claims
1. A ship data receiving method characterized by, The method comprises: Upon receiving the first service data sent by the sending ship, retrieving the first file data associated with the first service data; If the first file data is not retrieved, creating first current synchronization record information of the first file data, wherein the first current synchronization record information indicates that the first file data is in a synchronized state at the sending end and in an unsynchronized state at the receiving end; If the first file data is received, changing the first current synchronization record information to first latest synchronization record information, wherein the first latest synchronization record information indicates that the first file data is in a synchronized state at both the sending end and the receiving end; Upon receiving the second file data of the receiving ship, if the synchronization record information associated with the second file data is not retrieved, creating second current synchronization record information of the second file data, wherein the second current synchronization record information indicates that the second file data is in a synchronized state at the sending end and in an unsynchronized state at the receiving end; After receiving the second file data, changing the second current synchronization record information to second latest synchronization record information, wherein the second latest synchronization record information indicates that the second file data is in a synchronized state at both the sending end and the receiving end.
2. The method of claim 1, wherein, The first file data comprises a plurality of file data, and the method further comprises: checking whether all the file data in the first file data is in a synchronized state at the sending end; If yes, setting the version number of the receiving end to be the same as the version number of the sending end, and returning the first service data sending completion information to the sending end.
3. The method of claim 1, wherein, The second file data of the receiving ship comprises: listening to a message queue associated with the file data, and when an instruction message of the second file data is received, saving the position information, file identifier and md5 value of the second file data in the message queue to a redis memory database.
4. The method of claim 1, wherein, The method further comprises: checking whether the sum of the number of file data that currently exists and the number of file data that is being transmitted exceeds a preset number; If no, allocating memory space for the file data that is being transmitted; If yes, not allocating memory space for the file data that is being transmitted, and waiting for asynchronous processing.
5. The method of claim 1, wherein, The method further comprises: during the navigation of the ship, collecting motion characteristic parameters of the ship in real time, including roll angular velocity change rate, speed mutation rate and ship attitude angle; If the change rate of the motion characteristic parameters is detected to exceed a preset threshold, it is determined that the ship enters a dangerous working condition; According to a preset data value grading matrix, dynamically scoring the safety weight and time efficiency coefficient of the current service data and file data to be transmitted, and screening data types with a score higher than a threshold as high-priority labels; Through satellite link dual-channel design, the high-priority label data is allocated to a high-priority channel for real-time transmission, and the remaining data is allocated to a low-priority channel for asynchronous transmission.
6. The method of claim 5, wherein, If the change rate of the motion characteristic parameters is detected to not exceed the preset threshold, the method further comprises: automatically releasing the bandwidth resources occupied by the high-priority channel.
7. The method of claim 1, wherein, The method further comprises: Dividing the port area into virtual grids of a preset size based on location information, and assigning an independent red lock instance to each virtual grid; When a specified ship enters a target virtual grid, initiating a regional lock application request to the red lock instance corresponding to the target virtual grid; If the application is successful, activating a data transmission channel and transmitting the current to-be-transmitted business data and file data of the specified ship.
8. A ship data receiving device, characterized by Comprising: a retrieval unit that, upon receiving first business data sent by a ship, retrieves first file data associated with the first business data; a first creation unit that, if the first file data is not retrieved, creates first current synchronization record information of the first file data, the first current synchronization record information being in a synchronized state at the sending end and in an unsynchronized state at the receiving end; a first change unit that, upon receiving the first file data, changes the first current synchronization record information to first latest synchronization record information, the first latest synchronization record information being in a synchronized state at both the sending end and the receiving end; a second creation unit that, upon receiving second file data of the ship, creates second current synchronization record information of the second file data if synchronization record information related to the second file data is not retrieved, the second current synchronization record information being in a synchronized state at the sending end and in an unsynchronized state at the receiving end; a second change unit that, upon receiving the second file data, changes the second current synchronization record information to second latest synchronization record information, the second latest synchronization record information being in a synchronized state at both the sending end and the receiving end.
9. A ship data receiving apparatus characterized by comprising: Comprising: at least one processor; and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to: upon receiving first business data sent by a ship, retrieve first file data associated with the first business data; if the first file data is not retrieved, create first current synchronization record information of the first file data, the first current synchronization record information being in a synchronized state at the sending end and in an unsynchronized state at the receiving end; if the first file data is received, change the first current synchronization record information to first latest synchronization record information, the first latest synchronization record information being in a synchronized state at both the sending end and the receiving end; upon receiving second file data of the ship, create second current synchronization record information of the second file data if synchronization record information related to the second file data is not retrieved, the second current synchronization record information being in a synchronized state at the sending end and in an unsynchronized state at the receiving end; upon receiving the second file data, change the second current synchronization record information to second latest synchronization record information, the second latest synchronization record information being in a synchronized state at both the sending end and the receiving end.
10. A non-transitory computer storage medium, comprising, Computer executable instructions are stored, and the computer executable instructions are executed by a computer to implement: retrieving first file data associated with the first service data when receiving the first service data sent by the sending ship; if the first file data is not retrieved, creating first current synchronization record information of the first file data, the first current synchronization record information being in a synchronized state at the sending end and in a non-synchronized state at the receiving end; if the first file data is received, changing the first current synchronization record information into first latest synchronization record information, the first latest synchronization record information being in a synchronized state at both the sending end and the receiving end; when receiving second file data of the receiving ship, if synchronization record information related to the second file data is not retrieved, creating second current synchronization record information of the second file data, the second current synchronization record information being in a synchronized state at the sending end and in a non-synchronized state at the receiving end; after receiving the second file data, changing the second current synchronization record information into second latest synchronization record information, the second latest synchronization record information being in a synchronized state at both the sending end and the receiving end.
Citation Information
Patent Citations
Receiving and sending device and method and synchronizing system for achieving shipping industry data synchronization
CN105677885A
Data stream cooperative system under weak network condition
CN107609148A
Data synchronization method, apparatus, calculation device, and computer storage medium
CN109101622A
Background asynchronous ordering system and ordering method
CN110189206A
Ship-shore data synchronization method, device, equipment and medium
CN116527691A