Equipment upgrading method and device, equipment and storage medium
By using a block-based processing and merging upgrade mechanism for agent devices within a self-organizing network device group, the problem of excessive traffic consumption during device OTA upgrades is solved, achieving efficient device upgrades, reducing upgrade failure rates and traffic costs, and improving user experience.
Patent Information
- Application Number
- CN202511399973.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-28
- Publication Date
- 2026-01-02
AI Technical Summary
During the OTA upgrade process, existing technologies suffer from high upgrade failure rates, high data costs, and poor user experience, especially during large-scale device upgrades. This is mainly due to excessive data consumption and repeated file downloads caused by the point-to-point upgrade mechanism.
In a self-organizing network device group, devices select agent devices through a distributed consensus protocol. The agent devices download the files to be upgraded and process them in chunks. Non-agent devices obtain the files from the agent devices, process them in chunks, and merge them. This enables file distribution and upgrades within the devices, reducing direct interaction with the server.
By leveraging the distributed upgrade mechanism within the self-organizing network device cluster, the number of interactions with the server is significantly reduced, resolving the issue of excessive traffic consumption. This makes it suitable for environments with a large number of devices and limited network resources.
Smart Images

Figure CN121262084A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of ad hoc network device group, in particular to a device upgrading method and device, apparatus and storage medium. BACKGROUND
[0002] In the global perspective, there is a big difference in the development level of network infrastructure. In the current network environment, large model size, high data transmission time and high network device traffic are the common factors that make it difficult to overcome the current device OTA (Over The Air) upgrade process, and further cause high upgrade failure rate, poor user experience and high traffic cost. Especially when facing the OTA upgrade demand of large-scale devices, these problems are particularly obvious.
[0003] At present, the mainstream OTA upgrade method relies on a centralized file server for authorized distribution, and each device needs to establish a connection with the cloud independently and complete its own upgrade management task independently. In this process, the server needs to provide separate upgrade services for each device. This point-to-point upgrade mechanism will cause excessive consumption of traffic due to the phenomenon of repeated download of files by devices during the upgrade process. SUMMARY
[0004] The purpose of the embodiments of the present application is to provide a device upgrading method, apparatus, device and storage medium.
[0005] In order to achieve the above-mentioned purpose, the first aspect of the present application provides a device upgrading method applied to an ad hoc network device group, which comprises: In the case that any one device in the ad hoc network device group receives an upgrade instruction issued by a server, determine the to-be-upgraded devices in the network device group that have the same upgrade task; The to-be-upgraded devices select a proxy device based on a distributed consistency protocol; After the proxy device downloads the to-be-upgraded file from the server, the to-be-upgraded file is processed in blocks to obtain a plurality of file blocks; The non-proxy devices in the to-be-upgraded devices obtain the plurality of file blocks based on the proxy device and merge the plurality of file blocks to obtain the to-be-upgraded file; The proxy device and the non-proxy device upgrade based on the to-be-upgraded file.
[0006] In the embodiment of the present application, in the case that any one of the devices in the ad hoc network device group receives the upgrade instruction issued by the server, the device determines the to-be-upgraded devices in the ad hoc network device group that have the same upgrade task, including: in the case that any one of the devices in the ad hoc network device group receives the upgrade instruction issued by the server, obtaining a first identity verification key from the server; obtaining a second identity verification key of other devices in the ad hoc network device group; in the case that the first identity verification key and the second identity verification key are the same, determining that the device and the other devices are the to-be-upgraded devices that have the same upgrade task.
[0007] In the embodiment of the present application, the method further comprises: the proxy device calculates the first hash value corresponding to the plurality of file blocks; the non-proxy device calculates the second hash value corresponding to the plurality of file blocks; in the case that the first hash value and the second hash value are the same, the step of performing the merging processing on the plurality of file blocks to obtain the to-be-upgraded file is executed.
[0008] In the embodiment of the present application, the method further comprises: in the case that the file block download request sent by the non-proxy device is received, obtaining the list of allowed download devices associated with the file block; in the case that the list of allowed download devices includes the non-proxy device, the proxy device sends the file block to the non-proxy device.
[0009] In the embodiment of the present application, the method further comprises: in the case that the list of allowed download devices does not include the non-proxy device, the proxy device sends the list of allowed download devices to the non-proxy device, and the list of allowed download devices includes the historical download times of the allowed download devices; the non-proxy device selects a target device from the list of allowed download devices according to the historical download times of the allowed download devices, and sends a file block download request to the target device to obtain the file block from the target device.
[0010] In the embodiment of the present application, the method further comprises: in the case that the file block download request sent by the non-proxy device is received, the target device obtains the historical download times of the file block; in the case that the historical download times of the file block are less than the preset download times, the target device sends the file block to the non-proxy device.
[0011] In the embodiment of the present application, the method further comprises: in the case that the number of the non-proxy devices that complete the download reaches the preset number of devices, the step of performing the upgrade of the proxy device and the non-proxy device based on the to-be-upgraded file is executed.
[0012] The second aspect of the present application provides a device upgrade system, comprising an ad hoc network device group and a server, and the ad hoc network device group can implement the device upgrade method.
[0013] The third aspect of the present application provides a device upgrading apparatus, comprising: a memory configured to store instructions; and a processor configured to call the instructions from the memory and implement the device upgrading method when executing the instructions.
[0014] The fourth aspect of the present application provides a computer device, comprising: the device upgrading apparatus.
[0015] The fifth aspect of the present application provides a machine readable storage medium, which stores instructions for causing a machine to execute the device upgrading method.
[0016] Through the above technical solution, the devices in the ad hoc network do not need to download complete to-be-upgraded files from the server again through the internal self-closing loop mechanism, thereby significantly reducing the interaction times with the server and solving the problem of excessive consumption of traffic.
[0017] Other features and advantages of the embodiments of the present application will be described in detail in the following specific implementation part. BRIEF DESCRIPTION OF DRAWINGS
[0018] The accompanying drawings are included to provide a further understanding of the embodiments of the present application, and constitute a part of the specification, and are used together with the following specific implementation part to explain the embodiments of the present application, but do not constitute a limitation to the embodiments of the present application. In the drawings: Figure 1 A flowchart of the device upgrading method according to the embodiments of the present application is schematically shown; Figure 2 A proxy device election process diagram of the device upgrading method according to the embodiments of the present application is schematically shown; Figure 3 A flowchart of the device upgrading method according to the embodiments of the present application is schematically shown; Figure 4 A file transmission diagram of the device upgrading method according to the embodiments of the present application is schematically shown; Figure 5 An example diagram of the device upgrading method according to the embodiments of the present application is schematically shown; Figure 6 An example diagram of the device upgrading method according to the embodiments of the present application is schematically shown; Figure 7 A structural block diagram of the device upgrading apparatus according to the embodiments of the present application is schematically shown; Figure 8 An internal structural diagram of the computer device according to the embodiments of the present application is schematically shown. DETAILED DESCRIPTION
[0019] To make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. It should be understood that the specific implementation described herein is only used to illustrate and explain the embodiments of the present application and is not used to limit the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the scope of protection of the present application.
[0020] Figure 1 A flowchart of a device upgrading method according to an embodiment of the present application is schematically shown. As shown in Figure 1 The device upgrading method provided by the embodiments of the present application can be applied to a self-organizing network device group and can include the following steps. Step 101, in the case that any device in the self-organizing network device group receives an upgrading instruction issued by a server, determining a to-be-upgraded device in the self-organizing network device group that has the same upgrading task.
[0021] The self-organizing network device group refers to a set of devices that can automatically form and dynamically maintain network connection without relying on fixed infrastructure (such as routers and base stations). These devices can be directly interconnected through wireless communication (such as Wi-Fi, Bluetooth, Zigbee or LoRa).
[0022] First, any device in the self-organizing network device group will perform preliminary analysis and legality verification on the upgrading instruction issued by the server after receiving the upgrading instruction, and extract key upgrading task information such as task ID, target version number and file hash value.
[0023] In a feasible implementation, the current device encapsulates the information into a broadcast message suitable for internal communication of the self-organizing network, that is, an “upgrading task query” message, and sends the message to all reachable devices in the network by means of the broadcast mechanism of the self-organizing network. Other devices in the self-organizing network device group perform a self-checking process after receiving the broadcast message, such as judging whether the device model meets the requirements and whether the current version number is higher than the target version number, to determine whether the device belongs to the scope of the current upgrading. The device that passes the self-checking and is confirmed to be a device that needs to be upgraded will reply with an “upgrading task confirmation” message. Correspondingly, the current device can identify all to-be-upgraded devices in the self-organizing network device group that have the same upgrading task according to the “upgrading task confirmation” messages fed back by the remaining devices.
[0024] In another possible implementation, any one of the devices in the ad hoc network device group receives an upgrade instruction issued by the server, and obtains a first identity verification key from the server; obtains a second identity verification key of other devices in the ad hoc network device group; and in a case where the first identity verification key and the second identity verification key are the same, determines that the device and the other devices are to-be-upgraded devices having the same upgrade task.
[0025] After the current device receives the upgrade instruction issued by the server, the current device initiates an identity verification request to the server to obtain a first identity verification key for this upgrade. Similarly, after the other devices receive the upgrade instruction issued by the server, the other devices also respectively obtain second identity verification keys from the server.
[0026] Exemplarily, the device A broadcasts a "key verification request" message in the ad hoc network. Each device that has successfully obtained a second identity verification key returns a "key verification response" message to the device A after receiving the request, where the "key verification response" message carries the second identity verification key obtained by the device. The device A collects the second identity verification keys in all response messages and compares the second identity verification keys with the first identity verification key Key_A held by the device A. If there is at least one device (for example, the device B) that returns a key Key_B same as Key_A, it is determined that the device B and the device A belong to the same upgrade task. If no same key is matched, the device A will enter an independent upgrade process.
[0027] It can be understood that, compared with the way of transmitting a complete device list or state information in a conventional scheme, the key comparison mechanism adopted in the scheme has a lower calculation complexity, saves a large amount of bandwidth and storage space, and is especially suitable for a device environment with limited resources. In addition, the scheme accurately selects to-be-upgraded devices through key matching, and only allows legitimate devices to enter a subsequent upgrade process, thereby avoiding irrelevant devices from participating in proxy election or receiving upgrade files, and reducing network congestion and device load.
[0028] In step 102, a to-be-upgraded device selects a proxy device based on a distributed consistency protocol.
[0029] The core idea of the proxy device election mechanism based on the distributed consistency protocol is to ensure that, through a proposal submission stage and a proposal stage, a consensus on the proxy device is finally reached among multiple to-be-upgraded devices in the principle of minority submitting to majority.
[0030] In the first stage, the proposal submission stage, the purpose is to obtain a proposal number approved by a majority.
[0031] Each device to be upgraded generates a random waiting time (e.g. 0-5 seconds) before starting the election, to avoid multiple devices initiating proposals at the same time and causing conflicts. After the waiting time, the device acts as a proposer and broadcasts a proposal number N (initially starting from 0 and increasing, e.g. N = 1) to other devices.
[0032] The other devices act as voters and, after receiving the proposal number N, perform the following operations: compare N with the locally recorded maximum proposal number M. If N > M, update M = N and respond to the proposer with the content of the last proposal that passed; if N ≤ M, refuse to respond.
[0033] The proposer collects responses and, if the number of responses ≥ a first preset number (e.g. more than 1 / 2 of the total number of devices), enters the proposal phase. If the received responses contain a proposal with a higher number (indicating that other proposers have preemptively obtained majority support), the proposer terminates the current round and waits for the next round of random time before reinitiating the proposal.
[0034] In the second phase, the proposal phase, the purpose is to obtain a proposal content that is approved by a majority.
[0035] The proposer broadcasts the proposal number N and its proposal content to all devices.
[0036] The voters, after receiving the proposal, perform the following operations: compare N with the maximum proposal number M. If N > M, update M = N and respond to the proposer with the content of the current proposal that passed (explicitly support the current proposal); if N ≤ M, return the locally saved higher-numbered proposal content (to prevent old proposals from overriding new decisions).
[0037] The proposer collects responses and, if the number of responses ≥ a second preset number (e.g. more than 1 / 2 of the total number of devices), confirms itself as the proxy device. If the second preset number is not reached, the proposer extracts the highest-numbered proposal content from the responses, saves it as a local candidate solution, and waits for the next round of election.
[0038] Reference Figure 2 Schematic diagram of the proxy device election process.
[0039] Step 103: After the proxy device downloads the to-be-upgraded file from the server, the to-be-upgraded file is processed in blocks to obtain multiple file blocks.
[0040] The proxy device sends a request to the server to download the to-be-upgraded file, and the server starts to transmit the to-be-upgraded file to the proxy device after receiving the request. Then, the proxy device determines the file splitting mode according to a preset splitting strategy. The file can be split according to a fixed size, for example, 1 MB for each split, or the file can be dynamically split according to the content characteristics of the file by using a specific algorithm. According to the determined splitting rule, the proxy device splits the to-be-upgraded file into multiple file splits. During the splitting process, the proxy device adds corresponding identification information to each split, such as a split number and an identification of the file to which the split belongs, to facilitate subsequent transmission and merging operations.
[0041] In addition, the proxy device can also check each file split, calculate a first hash value or other check information corresponding to the file split, and use the first hash value or other check information for integrity verification when the non-proxy device receives the split.
[0042] Finally, the proxy device can broadcast the related information of the file split, such as the number of splits, the size of each split, and the identification information, to other to-be-upgraded devices through the ad hoc network, so that the other to-be-upgraded devices understand the situation of the file split and prepare for subsequent split acquisition.
[0043] Step 104: The non-proxy device other than the proxy device in the to-be-upgraded device acquires multiple file splits based on the proxy device and merges the multiple file splits to obtain the to-be-upgraded file.
[0044] In a feasible implementation, the non-proxy device sends a request to the proxy device to acquire the file split according to the related information of the file split broadcast by the proxy device and in combination with the demand and resource situation of the non-proxy device. The request can explicitly indicate the identification information of the required split, so that the proxy device can accurately identify and send the corresponding split. After receiving the request of the non-proxy device, the proxy device transmits the corresponding file split to the requesting non-proxy device. After receiving the file split, the non-proxy device determines the merging order of the split according to the identification information (such as the split number) of the split, and then merges the file splits in sequence to gradually build a complete to-be-upgraded file.
[0045] In addition, the proxy device can also check the integrity of each file split before merging the file split. The proxy device calculates a second hash value corresponding to the file split, extracts a first hash value from the identification information of the file split transmitted by the proxy device, and compares the first hash value with the second hash value. If the values are the same, it indicates that the file split transmitted by the proxy device has not been damaged or tampered with during the transmission process.
[0046] Step 105: The proxy device and the non-proxy device perform upgrading based on the to-be-upgraded file.
[0047] After the proxy device and the non-proxy device obtain the to-be-upgraded file, the proxy device and the non-proxy device can also perform overall checking on the to-be-upgraded file. For example, checking whether the hash value of the entire to-be-upgraded file is consistent with the hash value provided by the server, to ensure the integrity of the downloaded file.
[0048] In addition, the number of non-proxy devices that complete the downloading can be waited until the number reaches a preset device number (for example, more than 1 / 2 of the total number of devices), and then the proxy device and the non-proxy device are controlled to perform upgrading based on the to-be-upgraded file.
[0049] In the embodiments of the present application, when any device in the ad hoc network device group receives the upgrading instruction issued by the server, the to-be-upgraded device with the same upgrading task is first identified, and a proxy device is elected through a distributed consistency protocol. The proxy device is responsible for downloading the complete to-be-upgraded file from the server, and dividing the to-be-upgraded file into multiple file blocks. Subsequently, other non-proxy devices no longer directly download the complete file from the server, but obtain the file blocks from the proxy device through the internal network, and perform local merging processing, so as to restore the complete to-be-upgraded file. In this way, each device no longer needs to download the complete to-be-upgraded file from the server, and the phenomenon of repeated downloading of the file by the device in the upgrading process is fundamentally eliminated. The server only needs to focus on the communication with the proxy device, and does not need to establish a separate connection and transmit the file to each device, thereby effectively solving the problem of excessive consumption of traffic, and being particularly suitable for an ad hoc network environment with a large number of devices and limited network resources.
[0050] Figure 3 A flowchart of a device upgrading method according to an embodiment of the present application is schematically shown. As shown in Figure 3 In the embodiments of the present application, the method further includes: Step 301: In the case that the file block download request sent by the non-proxy device is received, the allowed download device list associated with the file block is obtained.
[0051] Step 302: In the case that the allowed download device list includes the non-proxy device, the proxy device sends the file block to the non-proxy device.
[0052] The allowed download device list is a device list maintained by the proxy device for each file block, which records the related information of the non-proxy device allowed to download the file block, and is used for managing the download authority of the file block.
[0053] Optionally, the proxy device continuously monitors the communication information in the ad hoc network, and when receiving a file chunk download request sent by a non-proxy device, extracts the identity information of the non-proxy device and the file chunk identifier of the requested file chunk. According to the file chunk identifier, the proxy device obtains the list of allowed download devices associated with the file chunk from the local storage, and then compares the identity information of the non-proxy device with the device information in the list of allowed download devices. If the non-proxy device is included in the list of allowed download devices, it means that the non-proxy device has the right to download the file chunk, and the proxy device sends the file chunk to the non-proxy device. Through the above steps, the proxy device can manage the file chunk download request of the non-proxy device according to the list of allowed download devices, ensuring that the legitimate device can obtain the required file chunk while ensuring the safe distribution of the file chunk.
[0054] Optionally, if the non-proxy device is not included in the list of allowed download devices, the proxy device sends a download rejection notification message to the non-proxy device, informing it that it has no right to download the file chunk. Alternatively, if the non-proxy device is not included in the list of allowed download devices, the proxy device sends the list of allowed download devices to the non-proxy device, which contains the historical download count information of the allowed download devices. Accordingly, after receiving the list of allowed download devices sent by the proxy device, the non-proxy device extracts the identity information of the allowed download devices and the corresponding historical download count, so as to select a target device according to its own strategy, such as selecting the device with the least historical download count to balance the download load among devices, or selecting the device with the most download count and the best network condition to improve the download success rate. Then, the non-proxy device sends a file chunk download request to the selected target device, and the request needs to clearly indicate the file chunk identifier of the required file chunk to obtain the required file chunk. As shown in FIG. 6, in the case where the non-proxy device is not allowed to directly download the file chunk from the proxy device, the required file chunk can be obtained from other allowed download devices by reasonably selecting the target device, ensuring the flexibility and effectiveness of the file chunk distribution process. Figure 4
[0055] Optionally, the target device continuously pays attention to the communication information in the ad hoc network, and when receiving the file chunk download request sent by the non-proxy device, the target device looks for the historical download record related to the file chunk according to the file chunk identifier specified in the request in the local storage. The historical download count information of the file chunk is extracted from the record, which reflects the download situation of the file chunk by other devices before. If the historical download count is less than the preset download count, it means that the file chunk has allocable download resources or the download pressure is within the bearable range, and the target device sends the file chunk to the non-proxy device. If the historical download count is greater than or equal to the preset download count, it is considered that the file chunk has had too many download operations, and there may be a risk of resource shortage or network congestion, and the target device sends a notification message of refusing download to the non-proxy device. Through the above steps, the target device can reasonably control the download of the file chunk according to the historical download count and the preset download count of the file chunk, meet the file chunk download demand of the non-proxy device on the premise of ensuring the load balancing of the device and the stability of the network, and avoid the centralization of the chunk transmission.
[0056] Exemplarily, as shown in Figure 5 , the proxy device downloads the file to be upgraded from the server and verifies the integrity, and after the verification is passed, the file is divided into multiple small files according to a fixed size, and the hash value of each file chunk is calculated for the non-proxy device in the networking to verify. The chunk transmission adopts a "chain fission" mode. Specifically, all non-proxy devices will continuously poll the proxy device to confirm whether the file download is completed. Once the proxy device completes the file download and the chunk operation, the routing information of the file chunk is returned to the non-proxy device. In order to limit only N devices to download, the proxy device sets an allowed download device list for recording the allowed download device list and the historical download count. When the non-proxy device initiates a file chunk download request, the proxy device verifies its legality based on the allowed download device list, and if it is legal, the file chunk is sent, and if it is not legal, the allowed download device list is returned, so that the non-proxy device can select a legal target device from the list for chunk transmission, as shown in Figure 4 . After a single device completes the download of all file chunks, it notifies other devices in the networking, and judges whether other devices have completed the download, and after confirming that more than half of the devices have completed the download, it enters the upgrade process uniformly.
[0057] Figure 6 An example schematic diagram of the device upgrade method in one embodiment.
[0058] Any one of the devices in the ad hoc network device group receives the upgrade instruction issued by the server (platform), obtains the wireless ad hoc network identity verification key from the server, and starts wireless sensing. Then, the device checks whether there is other device: if not, it enters the independent upgrade process; if yes, it records the information of other devices. Then, the device verifies whether it has the same identity verification key, and records the device information with the same upgrade task. After completing the traversal check of the devices, the election process is started to determine the proxy device. If the current device is selected as the proxy device, it will be responsible for downloading the upgrade file and verifying the integrity of the file. After the file is downloaded, the proxy device will split it and calculate the hash value of each block, while checking whether the download times of the blocks are over the limit. If not, the transmission of the file blocks is performed, and the routing information of the blocks is updated. During the transmission process, it is continuously checked whether all blocks have been transmitted, if not, the transmission is continued, if yes, the local upgrade sub-process is entered. For non-proxy devices, after confirming that the proxy device has completed the download, the routing information of the file blocks is requested, and the required blocks are downloaded. During the download process, the non-proxy device continuously checks whether all blocks have been downloaded, if yes, the file integrity is verified, and if the verification is passed, the local upgrade sub-process is entered.
[0059] It should be understood that, although Figure 6 the steps in the flowcharts are shown in sequence according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, the execution of these steps is not strictly limited in sequence, and these steps can be executed in other orders. Moreover, Figure 6 at least part of the steps in the flowcharts can include multiple sub-steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily sequential, but can be alternately executed with at least part of other steps or sub-steps or stages of other steps.
[0060] In one embodiment, as shown in Figure 7 , a device upgrade apparatus 700 is provided, comprising a to-be-upgraded device determination module, a proxy device confirmation module, a block processing module, a merging processing module, and an upgrade module, wherein: The to-be-upgraded device determination module 701 is configured to, in the case that any one of the devices in the ad hoc network device group receives the upgrade instruction issued by the server, determine the to-be-upgraded devices in the ad hoc network device group that have the same upgrade task.
[0061] The proxy device confirmation module 702 is configured to select the proxy device based on a distributed consensus protocol.
[0062] The block processing module 703 is configured to perform block processing on the to-be-upgraded file to obtain a plurality of file blocks after the proxy device downloads the to-be-upgraded file from the server.
[0063] The merging processing module 704 is configured to acquire the plurality of file blocks by the non-proxy device of the to-be-upgraded device other than the proxy device based on the proxy device, and perform merging processing on the plurality of file blocks to obtain the to-be-upgraded file.
[0064] The upgrading module 705 is configured to perform upgrading based on the to-be-upgraded file by the proxy device and the non-proxy device.
[0065] The device upgrading apparatus includes a processor and a memory, and the to-be-upgraded device determination module, the proxy device confirmation module, the block processing module, the merging processing module, and the upgrading module are stored in the memory as program units, and the processor executes the program units stored in the memory to realize the corresponding functions.
[0066] The processor includes a core, and the core calls the corresponding program units from the memory. The core can be one or more, and the device upgrading method is realized by adjusting the core parameters.
[0067] The memory can include a non-permanent memory in a computer readable medium, a random access memory (RAM), and / or a non-volatile memory such as a read-only memory (ROM) or a flash memory (flash RAM), and the memory includes at least one memory chip.
[0068] The embodiment of the present application provides a storage medium having a program stored thereon, and the program is executed by a processor to realize the device upgrading method.
[0069] The embodiment of the present application provides a processor, and the processor is used to run a program, and the program is executed to realize the device upgrading method.
[0070] In one embodiment, a computer device is provided, which can be a server, and an internal structure diagram of the computer device can be as shown in FIG. 8. Figure 8As shown in the figure. The computer device includes a processor A01, a network interface A02, a memory (not shown in the figure) and a database (not shown in the figure) connected through a system bus. Among them, the processor A01 of the computer device is used to provide computing and control capabilities. The memory of the computer device includes an internal memory A03 and a non-volatile storage medium A04. The non-volatile storage medium A04 stores an operating system B01, a computer program B02 and a database (not shown in the figure). The internal memory A03 provides an environment for the operating system B01 and the computer program B02 in the non-volatile storage medium A04 to run. The database of the computer device is used to store the allowed download device list and the like. The network interface A02 of the computer device is used to communicate with the external terminal through the network connection. The computer program B02 has realized a device upgrading method when executed by the processor A01.
[0071] Those skilled in the art can understand that, Figure 8 The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device to which the scheme of the present application is applied. The specific computer device can include more or fewer components than those shown in the figure, or combine certain components, or have a different component arrangement.
[0072] The embodiment of the present application provides a computer (electronic) device, the device includes a processor, a memory and a program stored in the memory and executable on the processor, and the processor executes the program to realize the steps of any one of the device upgrading methods.
[0073] The present application also provides a computer program product adapted to execute the program initialized with the steps of the device upgrading method when executed on a data processing device.
[0074] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system or a computer program product. Therefore, the present application can be in the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can be in the form of a computer program product implemented on one or more computer usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer usable program code.
[0075] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flow or blocks Figure 1 one or more flow or blocks
[0076] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks. Figure 1 one or more flow or blocks Figure 1 one or more flow or blocks
[0077] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flow or blocks Figure 1 one or more flow or blocks
[0078] In one typical configuration, the computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.
[0079] The memory can include non-persistent memory and / or persistent memory, such as flash memory, read-only memory (ROM), and / or volatile or non-volatile random access memory (RAM), among others. The memory is an example of computer readable media.
[0080] Computer-readable media includes permanent and non-permanent, movable and non-movable media that can implement information storage by any method or technology. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to a computing device. According to the definition herein, computer-readable media does not include transitory media such as modulated data signals and carriers.
[0081] It should also be noted that the terms "comprising", "containing", or any other variant thereof are intended to cover non-exclusive inclusions, so that a process, method, article or apparatus that includes a list of elements does not only include those elements, but also includes other elements not explicitly listed, or also includes elements inherent in such a process, method, article or apparatus. Without more limitations, the element defined by the statement "comprising a" does not exclude the presence of additional identical elements in the process, method, article or apparatus that includes the element.
[0082] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the scope of claims of the present application.
Claims
1. A device upgrade method, characterized by, The method is applied to a self-organizing network device group, and the method comprises: In the case that any device in the self-organizing network device group receives an upgrade instruction issued by a server, determining a to-be-upgraded device having the same upgrade task in the self-organizing network device group; The to-be-upgraded device selects an agent device based on a distributed consistency protocol; After the agent device downloads a to-be-upgraded file from the server, the to-be-upgraded file is processed in blocks to obtain a plurality of file blocks; The non-agent devices in the to-be-upgraded device other than the agent device acquire a plurality of the file blocks based on the agent device and merge the plurality of file blocks to obtain the to-be-upgraded file; The agent device and the non-agent devices upgrade based on the to-be-upgraded file.
2. The device upgrade method of claim 1, wherein, In the case that any device in the self-organizing network device group receives an upgrade instruction issued by a server, determining a to-be-upgraded device having the same upgrade task in the self-organizing network device group, comprising: In the case that any device in the self-organizing network device group receives an upgrade instruction issued by a server, acquiring a first identity verification key from the server; Acquiring a second identity verification key of other devices in the self-organizing network device group; In the case that the first identity verification key and the second identity verification key are the same, determining that the device and the other devices are to-be-upgraded devices having the same upgrade task.
3. The device upgrade method of claim 1, wherein, The method further comprises: The agent device calculates a first hash value corresponding to a plurality of the file blocks; The non-agent device calculates a second hash value corresponding to a plurality of the file blocks; In the case that the first hash value and the second hash value are the same, performing the step of merging a plurality of the file blocks to obtain the to-be-upgraded file.
4. The device upgrade method of claim 1, wherein, The method further comprises: In the case that a file block download request sent by the non-agent device is received, acquiring an allowed download device list associated with the file block; In the case that the allowed download device list includes the non-agent device, the agent device sends the file block to the non-agent device.
5. The device upgrade method of claim 4, wherein, The method further comprises: In the case that the allowed download device list does not include the non-agent device, the agent device sends the allowed download device list to the non-agent device, and the allowed download device list includes the historical download times of the allowed download devices; The non-agent device selects a target device from the allowed download device list according to the historical download times of the allowed download devices, and sends the file block download request to the target device to acquire the file block from the target device.
6. The device upgrade method of claim 5, wherein, The method further comprises: In the case that the file block download request sent by the non-agent device is received, the target device acquires the historical download times of the file block; In the case that the historical download times of the file block are less than a preset download time, the target device sends the file block to the non-agent device.
7. The device upgrade method of claim 1, wherein, The method further comprises: In a case where the number of the non-proxy devices completing the downloading reaches a preset device number, the step of performing the upgrading of the proxy device and the non-proxy device based on the to-be-upgraded file is executed.
8. A device upgrade system, comprising: The device upgrading system comprises a self-organizing network device group and a server, and the self-organizing network device group is capable of implementing the device upgrading method according to any one of claims 1 to 7.
9. An apparatus upgrade device, comprising: Comprising: a memory configured to store instructions; a processor configured to call the instructions from the memory and capable of implementing the device upgrading method according to any one of claims 1 to 7 when executing the instructions.
10. A computer device, comprising: Comprising: a device upgrading apparatus according to claim 9.
11. A machine-readable storage medium having instructions stored thereon, the instructions comprising: The instructions, when executed by the processor, cause the processor to be configured to implement the device upgrading method according to any one of claims 1 to 7.