A remote system upgrade method and system based on local area network peer-to-peer slice transmission

Abstract

This application discloses a remote system upgrade method and system based on local area network (LAN) peer-to-peer fragmented transmission. The method includes: the server dividing the complete system upgrade package into multiple fragments according to a preset data volume based on a configuration file; configuring multiple devices deployed in the same LAN as online nodes, and forming a peer-to-peer network based on the multiple online nodes, with each online node holding a portion of the fragments; in response to the upgrade command of the target device, the corresponding target node obtains the fragment information of other online nodes in the peer-to-peer network, and requests to download its missing target fragments based on the fragment information; the target node adds the downloaded target fragments to its local shared list and broadcasts its own fragment information in the peer-to-peer network, thereby sharing the downloaded fragments with other online nodes as a sharing node; after collecting all fragments, the target device exits the peer-to-peer network and enters the system upgrade process.

Description

Technical Field

[0001] This application relates to the field of terminal upgrade technology, and more specifically, to a remote system upgrade method and system based on local area network peer-to-peer segmented transmission. Background Technology

[0002] When existing Android devices undergo remote system upgrades using Over-the-Air (OTA) technology, the system typically initiates HTTP or HTTPS requests to a cloud server via the built-in UpdateEngine component. The server returns a complete OTA upgrade package, which the device then verifies after downloading and before invoking Android's native update engine to begin the upgrade process. When multiple devices are upgraded simultaneously, each independently downloads the same complete OTA package from the server.

[0003] In practice, existing OTA upgrade technologies often suffer from the following major drawbacks: First, when a large number of devices are upgraded simultaneously, the server bandwidth pressure increases linearly with the number of devices, leading to slow download speeds and frequent congestion and timeouts. Second, multiple devices on a local area network (LAN) repeatedly download the same complete OTA package, resulting in a significant waste of LAN bandwidth and server traffic. Third, with a centralized architecture, if the server malfunctions, all devices cannot be upgraded, posing a single point of failure risk. Fourth, the inability to utilize high-speed gigabit links within the LAN results in low upgrade efficiency, especially in large-scale mass production deployments where manually flashing upgrade packages is time-consuming, labor-intensive, and costly. Furthermore, existing technologies lack network self-healing capabilities, making upgrade failures easily caused by node disconnections or network fluctuations. Summary of the Invention

[0004] To address the technical problems existing in the aforementioned OTA upgrade technology, this application discloses a remote system upgrade method and system based on local area network (LAN) peer-to-peer segmented transmission. By dividing the complete upgrade package into multiple segments and utilizing a mechanism of simultaneous downloading and sharing among multiple devices within the LAN, the technical effect of accelerating the upgrade process as the number of devices increases is achieved while reducing server bandwidth pressure. Specifically, the technical solution of this application is as follows: In a first aspect, this application discloses a remote system upgrade method based on local area network peer-to-peer fragmented transmission, comprising the following steps: The server-side divides the complete system upgrade package into multiple fragments based on the preset data volume according to the configuration file. Multiple devices deployed in the same local area network are configured as online nodes, and a peer-to-peer network is formed based on the multiple online nodes, wherein each online node is configured to hold at least one of the shards; In response to the upgrade command of the target device, the corresponding target node obtains the fragment information of other online nodes in the peer-to-peer network, and requests the other online nodes to download the target fragment it is missing based on the fragment information, wherein the fragment information is used to indicate the status of the online node holding the fragment; The target node adds the downloaded target fragment to its local sharing list and broadcasts its own fragment information within the peer-to-peer network, thereby sharing the downloaded fragment with other online nodes as a sharing node. After all the fragments are collected, the target device exits the peer network and enters the system upgrade process to perform a system upgrade.

[0005] In some implementations, after the server divides the complete system upgrade package into multiple fragments based on a preset data volume according to the configuration file, it further includes: generating a fragment verification value for each fragment; After each target node downloads a target fragment, it obtains the fragment verification value corresponding to the target fragment and verifies the fragment verification value using a fragment verification algorithm; if the verification matches, the target fragment is retained and added to the shared list.

[0006] In some embodiments, the remote system upgrade method based on local area network peer-to-peer fragmented transmission further includes: After collecting all the fragments, the target device merges all the fragments into a complete system upgrade package in numerical order; The server generates a complete packet verification value based on the fragment verification values ​​of all fragments, and sends the complete packet verification value to the target device. The target device uses a whole-packet verification algorithm to verify the whole-packet verification value; if the verification is consistent, the system upgrade process is initiated.

[0007] In some implementations, the target device exits the peer-to-peer network and enters a system upgrade process to perform a system upgrade, specifically including: The target device sends an upgrade status notification to the server and reports its current device status; at the same time, it stops the fragment download and upload service, stops the data broadcast service, and exits the peer network; after exiting, it calls the device update engine to perform the upgrade.

[0008] In some implementations, the target device automatically restarts after the upgrade is completed and rejoins the peer-to-peer network service as a seed node. The seed node itself holds the complete system upgrade package and restarts the data broadcast service. The target device sends an upgrade success notification to the server and reports the upgrade result. It also includes: the target device receiving an upgrade package deletion command issued by the server, or automatically deleting the system upgrade package after waiting for a preset timeout period.

[0009] In some implementations, requesting the download of the missing target fragment from other online nodes based on the fragment information specifically includes: The target device calculates a list of missing target fragments; Based on the fragment information held by other online nodes, different target fragments are requested from multiple different nodes simultaneously, supporting parallel downloading by multiple nodes; When a node goes offline or a fragment transmission fails, the corresponding target fragment is automatically marked as a download failure and a new request is initiated. If no available node is found in the peer-to-peer network, the download will be redirected to the server.

[0010] In some implementations, the upgrade method is performed by importing the configuration file on the server side before proceeding. The configuration file specifically includes: the system upgrade package, a whitelist of device serial numbers allowed to participate in the upgrade, fragment size parameters, verification algorithm, timeout parameters for deleting the upgrade package, and upgrade strategy parameters.

[0011] Secondly, this application also discloses a remote system upgrade system based on local area network peer-to-peer segmented transmission, including: a server and multiple devices deployed in the same local area network; The server is used to divide the complete system upgrade package into multiple fragments based on a preset data volume according to the configuration file. The devices form a peer-to-peer network as online nodes, wherein each online node is configured to hold at least one of the shards; wherein each device includes: a node awareness module, a shard download module, a shard sharing module, and an upgrade execution module; The node awareness module is used to respond to the upgrade command of the target device and obtain the sharding information of other online nodes in the peer-to-peer network; The segment download module is used to request the download of its missing target segments from other online nodes based on the segment information; The fragment sharing module is used to add the downloaded target fragment to the local sharing list and broadcast its own fragment information within the peer-to-peer network, thereby acting as a sharing node to share the downloaded fragment with other online nodes; The upgrade execution module is used to control the target device to exit the peer network and enter the system upgrade process after all the fragments are collected to perform the system upgrade.

[0012] In some implementations, the server is also used to generate a fragment check value for each fragment; The fragment download module further includes a data verification unit; the data verification unit is used to obtain the fragment verification value corresponding to the target fragment after the node downloads each target fragment, and to verify the fragment verification value using a fragment verification algorithm; if the verification is consistent, the target fragment is retained and added to the shared list.

[0013] In other implementations, the server is configured with a visualization module; the visualization module supports global overview, single device download percentage tracking, upgrade result display, and anomaly alarm capabilities.

[0014] Compared with the prior art, this application has at least one of the following beneficial effects: 1. This application employs a local area network (LAN) peer-to-peer fragmentation concurrency mechanism. Only a small number of seed nodes need to obtain the complete upgrade package from the server. After the upgrade package is fragmented, it is multiplexed and transmitted across multiple points within the LAN. Devices requiring upgrades simultaneously pull different fragments from multiple neighboring nodes. Each device, while downloading, also uploads the obtained fragments to other devices. As the number of devices participating in the upgrade within the LAN increases, the number of available fragment source nodes in the network also increases synchronously, and the overall aggregated upload bandwidth continues to expand. Therefore, the upgrade speed is significantly accelerated, making it particularly suitable for large-scale concurrent upgrade scenarios. This solves the bandwidth bottleneck of centralized downloads, improves the speed of large-scale mass production upgrades, and reduces cloud pressure.

[0015] 2. During the fragment download process, if a node providing a fragment suddenly goes offline or times out, the system automatically marks the fragment as failed and immediately re-initiates a request to other nodes holding the same fragment. If no peer nodes are available on the local area network, the system automatically falls back to the server for backup download to ensure uninterrupted upgrades.

[0016] 3. This application features multi-point concurrency and automatic retry during the fragmented download process. Each fragment undergoes hash or CRC verification after transmission, and bad blocks are immediately retransmitted. After the entire packet is merged, a signature verification is performed. These multiple protection mechanisms significantly improve the success rate of upgrades in mass production environments.

[0017] 4. This application has built a visualization module on the server side, which supports real-time display of the total number of devices, the number of devices in each status, the overall completion rate, and the precise download percentage of each device in a global overview dashboard. It also provides functions such as fine-grained log backtracking for single devices, display of local area network P2P topology traffic, and automatic filtering and alarm of abnormal devices. Attached Figure Description

[0018] The preferred embodiments will now be described in a clear and easy-to-understand manner, in conjunction with the accompanying drawings, to further explain the above-mentioned characteristics, technical features, advantages, and implementation methods of this application.

[0019] Figure 1 This is a flowchart illustrating the steps of an embodiment of a remote system upgrade method based on local area network peer-to-peer fragmented transmission according to this application. Figure 2 This is a flowchart of a sub-step of step S3 in another embodiment of a remote system upgrade method based on local area network peer-to-peer fragmented transmission according to this application; Figure 3 This is a flowchart of a sub-step of step S4 in another embodiment of a remote system upgrade method based on local area network peer-to-peer fragmented transmission according to this application; Figure 4 This is a flowchart of a sub-step of step S5 in another embodiment of a remote system upgrade method based on local area network peer-to-peer fragmented transmission according to this application; Figure 5 This is a schematic diagram of the structural block of a device in one embodiment of a remote system upgrade system based on local area network peer-to-peer fragmented transmission according to this application; Figure 6 This is a functional structure diagram of the server-side visualization module of another implementation of a remote system upgrade system based on local area network peer-to-peer segmented transmission according to this application. Detailed Implementation

[0020] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0021] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or sets.

[0022] To keep the drawings concise, each figure only schematically shows the parts relevant to the invention, and these do not represent the actual structure of the product. Furthermore, to facilitate understanding, in some figures, only one of components with the same structure or function is schematically depicted, or only one is labeled. In this document, "one" not only means "only one," but can also mean "more than one."

[0023] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0024] Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0025] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the specific implementation methods of this application will be described below with reference to the accompanying drawings. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without creative effort.

[0026] Reference manual attached Figure 1 As shown, an embodiment of a remote system upgrade method based on local area network peer-to-peer fragmented transmission according to this application specifically includes the following steps: S1, the server divides the complete system upgrade package into multiple fragments based on the preset data volume according to the configuration file.

[0027] Specifically, the server first obtains the complete system upgrade package. The server then divides this complete upgrade package into multiple data blocks according to a preset fragment size (e.g., 64KB / 128KB / 1MB bytes), each data block being called a "fragment". In practice, relevant technical personnel can weigh the self-negotiation settings for fragment size based on the monitoring needs of mass production scenarios. Smaller fragments allow for more granular progress reporting, but also result in higher reporting frequency and greater network overhead.

[0028] In addition, pre-setting data volume fragments facilitates the establishment of a unified fragment number index, enabling the device to accurately track which fragments have been downloaded and which fragments are still missing, providing a basis for resuming interrupted downloads and retransmitting bad blocks.

[0029] S2, multiple devices deployed in the same local area network are configured as online nodes, and a peer-to-peer network is formed based on the multiple online nodes, wherein the online nodes are configured to hold at least one of the shards.

[0030] Specifically, in a peer-to-peer network, all devices are online nodes that are peers. Each online node can both request data from other devices and provide data to other devices.

[0031] The core upgrade logic for online nodes uses P2P sharding acceleration. The server acts as the control center, responsible for importing configurations before the upgrade, monitoring status during the upgrade, and managing upgrade packages after the upgrade.

[0032] In the following implementation, online nodes can be divided into the following three types of node roles, as detailed below: Seed node: This refers to the device that first obtains the complete upgrade package from the cloud / server, or retains the complete upgrade package after the upgrade is completed, and can provide fragmented downloads to other nodes.

[0033] Peer nodes: These nodes own a portion of the data and can upload data to other devices. They continue to participate in the P2P network when not in an upgrade state.

[0034] Download node (Leech node): This indicates a node that is currently downloading a fragment. Once the download is complete, it will immediately exit the P2P network and enter a system upgrade state. During the upgrade, it will not participate in any fragment transmission.

[0035] The above three types of node roles switch dynamically based on the actions they perform.

[0036] Each online node holds a portion of the entire upgrade package fragments, and different devices may have different sets of fragments. This setup leverages the principles of distributed storage: the complete data is distributed across multiple nodes, and when a new device needs an upgrade, it can simultaneously obtain different fragments from multiple neighboring nodes, instead of downloading everything from the central server. As the number of nodes holding fragments increases, the aggregated upload bandwidth of the entire peer-to-peer network also expands.

[0037] S3, in response to the upgrade command of the target device, the corresponding target node obtains the fragment information of other online nodes in the peer-to-peer network, and requests the other online nodes to download the target fragment it is missing based on the fragment information, wherein the fragment information is used to indicate the status of the online node holding the fragment.

[0038] Specifically, the target node device that needs to be remotely upgraded sends a probe message to the local area network via User Datagram Protocol broadcast or multicast. Other online nodes receive the message and reply with their own existence information and a list of fragment numbers they hold, thus allowing the target node to know which data sources are available in the network.

[0039] In some alternative implementations, the target node builds a mapping table based on the collected information, recording the network address of each online node and which fragment numbers that node holds. It then compares its own list of held fragments with the total list of fragments to calculate the set of missing target fragments, thereby enabling the formulation of an optimal download strategy.

[0040] In some alternative implementations, the target node requests different fragments from multiple nodes simultaneously, utilizing the multi-link parallel transmission capability of the local area network to ensure that the download speed is not limited by the upload bandwidth of a single node.

[0041] S4, the target node adds the downloaded target fragment to its local sharing list and broadcasts its own fragment information within the peer-to-peer network, thereby sharing the downloaded fragment with other online nodes as a sharing node.

[0042] Specifically, the target node periodically sends its own shard information to all devices in the local area network via the User Datagram Protocol (UDP), enabling other nodes to promptly discover that the node has added a usable data source.

[0043] The download-and-share mechanism in this application allows devices to begin contributing to other nodes during the download process. As the download progresses, the types and number of fragments provided by each node continuously increase, resulting in a dynamic growth trend in the overall network's service capacity. This design simultaneously transforms each newly joined downloader into an uploader, enabling network resources to self-enhance as the number of devices increases.

[0044] S5, after all the fragments are collected, the target device exits the peer network and enters the system upgrade process to perform a system upgrade.

[0045] Specifically, once the target node has locally collected all fragments of the system upgrade package and verified that all fragments are complete, it exits the peer-to-peer network. At this point, the target node stops sending User Datagram Protocol (UDP) broadcast messages, closes the peer-to-peer network transmission port, and no longer responds to fragment requests from other nodes or obtains data from other nodes. This ensures that the upgrade process is performed in a clean and isolated environment, while avoiding the negative impact of invalid requests or timeouts on other nodes.

[0046] Optionally, after the target node exits the peer-to-peer network, all fragments are merged into a complete system upgrade package in numerical order. The upgrade package is then passed to the native Android update engine, which performs subsequent signature verification, full package verification, system flashing, and other operations to finally complete the OTA remote system upgrade.

[0047] In some implementations, the upgrade method is performed by importing the configuration file on the server side before proceeding.

[0048] The configuration file specifically includes: the system upgrade package, a whitelist of device serial numbers allowed to participate in the upgrade, fragment size parameters, verification algorithm, timeout parameters for deleting the upgrade package, and upgrade strategy parameters.

[0049] Specifically, after the configuration file is imported, the server parses, verifies, and stores it, and performs subsequent operations such as upgrade package splitting, whitelist filtering, and upgrade notification push according to the configuration content.

[0050] This application provides another embodiment of a remote system upgrade method based on local area network peer-to-peer segmented transmission. Based on any embodiment of the above method, refer to the appendix to the specification. Figure 2 As shown, in step S3: requesting the download of the missing target fragment from other online nodes based on the fragment information, specifically includes: S31, the target device calculates a list of missing target fragments.

[0051] Specifically, the target device needs to define its own download requirements and build a set of all fragment numbers that it has not yet downloaded and needs to obtain from other nodes.

[0052] S32, based on the fragment information held by other online nodes, simultaneously request different target fragments from multiple different nodes, supporting parallel downloading by multiple nodes.

[0053] Specifically, based on the established node fragmentation mapping table, the device selects one or more online nodes holding the fragment for each fragment in the target fragmentation list, and then simultaneously initiates multiple Transmission Control Protocol (TCP) connections to request different fragments from different nodes.

[0054] Multi-node parallel download means that the target device establishes connections with multiple nodes within the same time period, and each connection is responsible for transmitting an independent fragment.

[0055] S33, when a node goes offline or a fragment transmission fails, the corresponding target fragment is automatically marked as a download failure and a new request is initiated.

[0056] Specifically, during fragmented transmission, download failures may occur due to factors such as a node actively leaving the network, network fluctuations, node device shutdown, or transmission timeout. The target device will mark the corresponding failed target fragment, then add the fragment back to the request queue and re-initiate a download request to other nodes holding the fragment. The automatic retry mechanism enables the target device to quickly switch to other available nodes, ensuring that the download process is not interrupted by a single point of failure and can be restored without manual intervention.

[0057] S34, if there are no available nodes in the peer-to-peer network, the process will fall back to the server for downloading.

[0058] Specifically, if no available nodes are available within the peer-to-peer network, the target device will switch download sources and directly initiate a Hypertext Transfer Protocol (HTTP) or Secure HTTP request to the server to download the missing fragment. This fallback mechanism is designed to provide a safety net for the peer-to-peer network.

[0059] Based on any of the above embodiments, this application discloses another embodiment of a remote system upgrade method based on local area network peer-to-peer fragmented transmission, wherein after step S1, the method further includes: generating a fragmented verification value for each fragment.

[0060] Optionally, the fragment checksum is calculated using a secure hash algorithm (such as SHA256) or a cyclic redundancy check algorithm (such as CRC32), with each fragment corresponding to a unique checksum. The fragment checksum allows the receiver to independently verify the correctness of the fragment after receiving it, ensuring that only complete and tamper-proof fragments are retained and further shared.

[0061] It should be noted that although this application illustrates the specific type of algorithm used, those skilled in the art can choose other existing encryption algorithms to calculate the fragment verification value in specific implementations, and this application does not specifically limit it.

[0062] In step S4: the target node adds the downloaded target fragment to its local shared list. (See attached instruction manual.) Figure 3 As shown, the specific steps include the following: S41, after each target shard is downloaded, the target node obtains the shard verification value corresponding to the target shard.

[0063] S42, the fragment verification algorithm is used to verify the fragment verification value. If the verification is consistent, the target fragment is retained and added to the shared list.

[0064] Specifically, the fragment checksum is attached to the downloaded target fragment. After receiving the fragment data, the target node uses the same fragment checksum algorithm as the server to calculate the actual checksum. This actual checksum is then compared with the fragment checksum pre-sent by the server. If they match, it means the fragment has not been damaged or tampered with during transmission, and the verification passes. If they do not match, it means the fragment has been damaged or tampered with, and the verification fails.

[0065] For a verified shard, the target node retains it in its local storage and adds its shard number to its local shared list. In the next broadcast, it announces the ownership information of the shard to the peer network, thus becoming a sharing node that can provide the shard to other nodes.

[0066] For a fragment that fails to be verified, the target node discards it and re-initiates a download request to other nodes or servers that hold the fragment.

[0067] This application provides another embodiment of a remote system upgrade method based on local area network peer-to-peer fragmented transmission, which, in addition to the above method embodiment, further includes: S43, after collecting all the fragments, the target device merges all the fragments into a complete system upgrade package in numerical order.

[0068] Specifically, the target device reads all the fragmented files stored locally, and concatenates and combines the binary data of each fragment in the order of its corresponding number to restore the complete system upgrade package.

[0069] S44, the server generates a complete packet verification value based on the fragment verification values ​​of all fragments, and sends the complete packet verification value to the target device.

[0070] In some optional implementations, the server concatenates the fragment checksums of all fragments into a continuous checksum sequence in fragment number order, and then performs a hash operation on this sequence to obtain the complete packet checksum. The server sends the generated complete packet checksum to the target device so that, after fragment verification, it can further provide final complete packet verification for the merged upgrade package.

[0071] S45, the target device uses a whole-packet verification algorithm to verify the whole-packet verification value. If the verification matches, the system upgrade process begins.

[0072] Specifically, after the target device completes the fragment merging to obtain the complete system upgrade package, it obtains the full package verification value pre-sent by the server and uses the same full package verification algorithm (such as SHA256) as the server to calculate the actual full package verification value. Then, the actual full package verification value is compared with the full package verification value sent by the server.

[0073] If both match, the merged upgrade package is complete, in the correct order, and has not been tampered with, and the verification passes. If they do not match, an error occurred during the merging process or the upgrade package is corrupted, and the verification fails.

[0074] If the verification is successful, the target device confirms that the upgrade package is valid, then actively exits the peering network and enters the system upgrade process, calling the Android native update engine to perform the upgrade.

[0075] In the event of verification failure, the target device will clear all local fragments and re-download them to avoid performing the upgrade with incorrect data.

[0076] By verifying the entire package checksum, the target device can make a final confirmation of the correctness of the upgrade package before entering the upgrade process, thus intercepting risks.

[0077] Based on the above embodiments, this application discloses another embodiment of a remote system upgrade method based on local area network peer-to-peer fragmented transmission, as detailed in the appendix to the specification. Figure 4As shown, step S5: The target device exits the peer-to-peer network and enters the system upgrade process to perform a system upgrade, specifically including: S51, the target device sends an upgrade status notification to the server and reports its current device status.

[0078] Specifically, after the target device collects all the fragments and completes the whole packet verification, it will send a status notification message to the server via the network.

[0079] Optionally, in some implementations, the notification to enter upgrade status includes information such as the current device serial number, upgrade version, and upgrade progress percentage.

[0080] S52, stop the fragment download and upload service, stop the data broadcast service, and exit the peer network.

[0081] Specifically, perform the following exit operations: First, close all ongoing Transmission Control Protocol (TCP) fragmentation transmission connections, cease downloading fragments from other nodes, and stop responding to fragmentation requests from other nodes. Second, stop the User Datagram Protocol (UDP) periodic broadcast service, and stop sending fragmentation information held by the user to the local area network. Finally, release the port and memory resources occupied by the peer network, completing a complete exit from the peer network.

[0082] S53, after exiting, calls the device update engine to perform an upgrade.

[0083] Specifically, exiting and then re-invoking ensures that the update engine will not conflict with peer-to-peer network services during the upgrade process. Optionally, the device update engine includes two modes: A / B upgrade and Recovery upgrade.

[0084] A / B upgrade involves dividing the device's storage space into two independent system partitions, A and B. When the device is currently running on partition A, the update engine writes the new system to partition B. After the write is complete, the device reboots and automatically switches to partition B for booting. Recovery upgrade involves the device rebooting into an independent, lightweight system environment. The update engine overwrites the currently used system partition with the new system. After the write is complete, the device reboots again to boot into the new system.

[0085] This application retains the native system update engine (UpdateEngine) and only replaces the download engine with a peer-to-peer network service, ensuring full compatibility with the native Android system upgrade process. It requires no modification to the underlying system, significantly reducing development costs and system compatibility risks.

[0086] In other embodiments, it also includes: S54, the target device automatically restarts after the upgrade is completed and rejoins the peer-to-peer network service as a seed node. The seed node itself holds the complete system upgrade package and restarts the data broadcast service.

[0087] Specifically, a seed node is a node that possesses the complete system upgrade package and can provide full fragment download services to any other device that needs an upgrade. At this point, the device restarts User Datagram Protocol (UDP) broadcasting, periodically sending its fragment information to the local area network.

[0088] In large-scale production scenarios, as more and more devices complete upgrades, the number of seed nodes in the network continues to increase, and the aggregated upload bandwidth of the entire peer-to-peer network continues to expand.

[0089] S55, the target device sends an upgrade success notification to the server and reports the upgrade result.

[0090] Specifically, after the target device restarts and rejoins the peering network, it sends an upgrade success notification message to the server via the network. This message includes information such as the device serial number, upgrade version, upgrade result status (successful), and upgrade time. Upon receiving the notification, the server updates the device's status from "Upgrading" to "Successful" and marks the device as having completed the upgrade on the visual dashboard.

[0091] S56, the target device receives an upgrade package deletion command issued by the server, or automatically deletes the system upgrade package after waiting for a preset timeout period.

[0092] Specifically, after the target device completes the upgrade and reports the success, it will not immediately delete the local system upgrade package, but will instead enter a retention and waiting phase.

[0093] In some implementations, after receiving a unified deletion command from the server, the target device cleans up the upgrade package and all fragment data stored locally.

[0094] In other implementations, the target device automatically deletes the locally stored upgrade package and all fragment data after a preset timeout period in the configuration file expires. The preset timeout period is set in advance in the configuration file by relevant technical personnel.

[0095] Based on the same concept, this application also discloses a remote system upgrade system based on local area network (LAN) peer-to-peer segmented transmission. The system is used to implement the steps described in any of the above method embodiments. Specifically, one embodiment of the remote system upgrade system based on LAN peer-to-peer segmented transmission in this application includes: a server and multiple devices deployed within the same LAN.

[0096] The server is used to divide the complete system upgrade package into multiple fragments based on a preset data volume according to the configuration file.

[0097] The devices form a peer-to-peer network as online nodes, wherein each online node is configured to hold at least one of the shards. (See attached specification.) Figure 5 As shown, each of the devices includes: a node perception module, a fragment download module, a fragment sharing module, and an upgrade execution module.

[0098] The node awareness module is used to respond to the upgrade command of the target device and obtain the sharding information of other online nodes in the peer-to-peer network.

[0099] The fragment download module is used to request the download of the missing target fragments from other online nodes based on the fragment information.

[0100] The fragment sharing module is used to add the downloaded target fragment to the local sharing list and broadcast its own fragment information within the peer-to-peer network, thereby acting as a sharing node to share the downloaded fragment with other online nodes.

[0101] The upgrade execution module is used to control the target device to exit the peer network and enter the system upgrade process after all the fragments are collected to perform the system upgrade.

[0102] Based on the above embodiments, this application discloses another embodiment of a remote system upgrade system based on local area network peer-to-peer fragmented transmission. The fragmented download module further includes a data verification unit. The data verification unit is used to obtain the fragment verification value corresponding to the target fragment after each target fragment is downloaded by the node, and to verify the fragment verification value using a fragmented verification algorithm. If the verification is consistent, the target fragment is retained and added to the shared list.

[0103] In other implementations, the server generates a complete package verification value based on the fragment verification values ​​of all fragments and sends the complete package verification value to the target device. The data verification unit is further configured to, after all fragments are collected, have the target device merge all fragments into a complete system upgrade package in numerical order, and then verify the complete package verification value using a complete package verification algorithm. If the verification matches, the system upgrade process begins.

[0104] Based on the above embodiments, this application discloses another embodiment of a remote system upgrade system based on local area network peer-to-peer fragmented transmission, as detailed in the appendix to the specification. Figure 6As shown, the server is configured with a visualization module. This visualization module supports functions such as global overview, device download percentage tracking, upgrade result display and anomaly alarm capabilities, and batch device monitoring.

[0105] In some alternative implementations, the device immediately reports its current status to the server when its status changes. For example, it reports the status every time 1% of the download progress is completed, or every 10 segments are downloaded. It also reports any anomalies immediately.

[0106] The server-side visualization module can display the current device status, such as: WAITING (awaiting upgrade), DISCOVERING (node ​​discovery in progress), DOWNLOADING (downloading in progress), MERGING (merging and verification in progress), ENTERING_UPGRADE (entering upgrade state, exiting P2P network), UPGRADING (system flashing in progress), SUCCESS (upgrade successful), and FAILED (upgrade failed).

[0107] In some alternative implementations, the visualization module is designed for batch equipment operation and maintenance in mass production scenarios, and consists of a five-layer architecture: a data receiving layer, a data storage layer, a visualization rendering layer, a control command layer, and an alarm layer. The core implementation involves the following: Bypass Non-Intrusive: It does not interfere with the main process of peer-to-peer network upgrades on the device side, only receives reported data, has no downlink control commands, and does not introduce additional points of failure.

[0108] Low resource consumption: The device reports using a lightweight text protocol, with each data packet being less than 200 bytes, thus not consuming upgrade bandwidth.

[0109] High compatibility: Supports both local area network and public network deployment modes for production lines, adapting to all scenarios of mass production and remote operation and maintenance of existing equipment in factories.

[0110] The core processing logic on the server side includes: 1. Data reception: Start the TCP service to receive status and progress data reported by the device, supporting tens of thousands of devices reporting concurrently.

[0111] 2. Data parsing and verification: Verify the validity of the device serial number and OTA version of the reported data, and filter invalid data.

[0112] 3. Data storage: Real-time writing to the time-series database to store upgrade data for a single device throughout its entire lifecycle and global progress statistics.

[0113] 4. Data aggregation: Real-time aggregation and calculation of global upgrade statistics based on OTA version, production line, equipment batch, and other dimensions.

[0114] The core visualization dimensions include: 1. Global Upgrade Overview Dashboard: Displaying the total number of devices in the current upgrade batch, the number of devices in each status (pending upgrade / node discovery / downloading / merging and verification / upgrading / success / failure), overall completion rate, and average upgrade time. In some implementations, the visualization module displays the download percentage of each device in real time, accurate to 1%. It is also used to display upgrade progress trend charts, showing the overall completion rate changing over time in real time.

[0115] 2. Detailed Progress Tracking for Individual Devices: Filter by device serial number / IP to display the real-time upgrade progress of a single device, its current stage, number of downloaded fragments, number of missing fragments, and number of connected P2P nodes. Optionally, it also supports full-process log backtracking for a single device, including node discovery, fragment download, verification, exit from the P2P network, and time points and anomaly information for the entire upgrade process. This clearly indicates whether the device has been successfully upgraded.

[0116] 3. LAN P2P Topology Visualization: Visualizes the node relationships within the current LAN, the distribution of Seed nodes, the shard holdings of each node, and the shard transmission flow. It also provides statistics on the upload / download traffic of each node, intuitively presenting the P2P acceleration effect.

[0117] 4. Centralized Display of Abnormal Equipment: Automatically filters abnormal equipment that has failed upgrades, stalled progress, or failed verifications, displaying the cause of the abnormality, the time of occurrence, and equipment information. Supports one-click export of abnormal equipment for easy location and handling by production line maintenance personnel.

[0118] In some alternative implementations, the processor of this application also possesses mass production and maintenance support capabilities. This is illustrated in the following examples: 1. Threshold Alarm: For abnormal scenarios such as upgrade failure, progress stagnation exceeding the preset time, and verification failure, alarm information will be pushed through pop-ups, emails, etc.

[0119] 2. Data Export: Supports exporting upgraded reports, equipment details, and anomaly lists to Excel format to meet the needs of mass production traceability and archiving.

[0120] 3. Historical data query: Supports querying historical upgrade records by batch, time, device model, and OTA version for data analysis and optimization.

[0121] 4. Configuration file import: Supports maintenance personnel to import configuration files containing OTA packages and device SN whitelists, and start batch upgrades with one click.

[0122] 5. Batch Management Operations: After confirming successful upgrades for all devices on the visual dashboard, a unified command to delete OTA packages can be sent to all devices with a single click. Operations such as triggering a re-upgrade for a single device and forcibly deleting OTA packages are also supported.

[0123] The remote system upgrade method and system based on local area network peer-to-peer segmented transmission in this application have the same technical concept, and the technical details of the embodiments of the two are applicable to each other. To reduce repetition, they will not be repeated here.

[0124] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of program modules is merely an example. In practical applications, the above functions can be assigned to different program modules as needed, that is, the internal structure of the device can be divided into different program units or modules to complete all or part of the functions described above. The program modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software program unit. Furthermore, the specific names of the program modules are only for easy differentiation and are not intended to limit the scope of protection of this application.

[0125] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A remote system upgrade method based on local area network peer-to-peer fragmented transmission, characterized in that, Includes the following steps: The server-side divides the complete system upgrade package into multiple fragments based on the preset data volume according to the configuration file. Multiple devices deployed in the same local area network are configured as online nodes, and a peer-to-peer network is formed based on the multiple online nodes, wherein each online node is configured to hold at least one of the shards; In response to the upgrade command of the target device, the corresponding target node obtains the fragment information of other online nodes in the peer-to-peer network, and requests the other online nodes to download the target fragment it is missing based on the fragment information, wherein the fragment information is used to indicate the status of the online node holding the fragment; The target node adds the downloaded target fragment to its local sharing list and broadcasts its own fragment information within the peer-to-peer network, thereby sharing the downloaded fragment with other online nodes as a sharing node. After all the fragments are collected, the target device exits the peer network and enters the system upgrade process to perform a system upgrade.

2. The remote system upgrade method based on local area network peer-to-peer fragmented transmission as described in claim 1, characterized in that, After the server divides the complete system upgrade package into multiple fragments based on the preset data volume according to the configuration file, it also includes: generating a fragment verification value for each fragment. After each target node downloads a target fragment, it obtains the fragment verification value corresponding to the target fragment and verifies the fragment verification value using a fragment verification algorithm; if the verification matches, the target fragment is retained and added to the shared list.

3. The remote system upgrade method based on local area network peer-to-peer fragmented transmission as described in claim 2, characterized in that, Also includes: After collecting all the fragments, the target device merges all the fragments into a complete system upgrade package in numerical order; The server generates a complete packet verification value based on the fragment verification values ​​of all fragments, and sends the complete packet verification value to the target device. The target device uses a whole-packet verification algorithm to verify the whole-packet verification value; If the verification is successful, proceed to the system upgrade process.

4. The remote system upgrade method based on local area network peer-to-peer fragmented transmission as described in claim 1, characterized in that, The target device exits the peer-to-peer network and enters the system upgrade process to perform a system upgrade, specifically including: The target device sends an upgrade status notification to the server and reports its current device status; at the same time, it stops the fragment download and upload service, stops the data broadcast service, and exits the peer network; after exiting, it calls the device update engine to perform the upgrade.

5. The remote system upgrade method based on local area network peer-to-peer fragmented transmission as described in claim 1, characterized in that: The target device automatically restarts after the upgrade is completed and rejoins the peer-to-peer network service as a seed node. The seed node itself holds the complete system upgrade package and restarts the data broadcast service. The target device sends an upgrade success notification to the server and reports the upgrade result. It also includes: the target device receiving an upgrade package deletion command issued by the server, or automatically deleting the system upgrade package after waiting for a preset timeout period.

6. The remote system upgrade method based on local area network peer-to-peer fragmented transmission as described in claim 1, characterized in that, The method of requesting to download the missing target fragment from other online nodes based on the fragment information specifically includes: The target device calculates a list of missing target fragments; Based on the fragment information held by other online nodes, different target fragments are requested from multiple different nodes simultaneously, supporting parallel downloading by multiple nodes; When a node goes offline or a fragment transmission fails, the corresponding target fragment is automatically marked as a download failure and a new request is initiated. If no available node is found in the peer-to-peer network, the download will be redirected to the server.

7. The remote system upgrade method based on local area network peer-to-peer fragmented transmission as described in claim 1, characterized in that, Before executing the upgrade method, the process also includes: importing the configuration file on the server side; The configuration file specifically includes: the system upgrade package, a whitelist of device serial numbers allowed to participate in the upgrade, fragment size parameters, verification algorithm, timeout parameters for deleting the upgrade package, and upgrade strategy parameters.

8. A remote system upgrade system based on local area network peer-to-peer fragmented transmission, characterized in that, include: The server and multiple devices deployed on the same local area network; The server is used to divide the complete system upgrade package into multiple fragments based on a preset data volume according to the configuration file. The devices form a peer-to-peer network as online nodes, wherein each online node is configured to hold at least one of the shards; wherein each device includes: a node awareness module, a shard download module, a shard sharing module, and an upgrade execution module; The node awareness module is used to respond to the upgrade command of the target device and obtain the sharding information of other online nodes in the peer-to-peer network; The segment download module is used to request the download of its missing target segments from other online nodes based on the segment information; The fragment sharing module is used to add the downloaded target fragment to the local sharing list and broadcast its own fragment information within the peer-to-peer network, thereby acting as a sharing node to share the downloaded fragment with other online nodes; The upgrade execution module is used to control the target device to exit the peer network and enter the system upgrade process after all the fragments are collected to perform the system upgrade.

9. A remote system upgrade system based on local area network peer-to-peer fragmented transmission as described in claim 8, characterized in that, The server is also used to generate a fragment verification value for each fragment. The fragment download module further includes a data verification unit; the data verification unit is used to obtain the fragment verification value corresponding to the target fragment after the node downloads each target fragment, and to verify the fragment verification value using a fragment verification algorithm; if the verification is consistent, the target fragment is retained and added to the shared list.

10. A remote system upgrade system based on local area network peer-to-peer fragmented transmission as described in claim 8, characterized in that, The server is equipped with a visualization module; the visualization module supports global overview, single device download percentage tracking, upgrade result display, and anomaly alarm capabilities.

Images