Online upgrading method and system for computer software

Abstract

The invention relates to an online upgrading method and system for computer software, and belongs to the field of computer software. After a terminal sends an upgrading request to a server, information of a current version and information of a target version are received and compared, and a version difference list is generated; and the server generates an increment upgrade package according to the increment upgrade package, splits the increment upgrade package into data fragments with serial numbers, and sends fragment hash values and target hash values at the same time. The terminal receives the fragments in sequence, verifies the hash values in real time, and requests retransmission if the hash values are inconsistent; and after all the effective fragments are received, splicing the effective fragments into a complete incremental package, and synthesizing the complete incremental package with local software to obtain synthesized software. And the terminal calculates an actual overall hash value of the synthetic software, generates a dynamic verification secret key by combining the optical fiber fluctuation data and the basic secret key, compares the encrypted dynamic verification secret key with a target hash value encrypted by the server, and completes upgrading if the encrypted dynamic verification secret key is consistent with the target hash value. According to the method, the upgrading efficiency, accuracy and safety are improved through incremental transmission, fragment verification and dynamic secret key verification.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and in particular to an online upgrade method and system for computer software. Background Technology

[0002] In the field of online upgrades for computer software, traditional upgrade solutions have long faced multiple challenges related to efficiency, stability, and security. Full package upgrades, as an early mainstream method, require the terminal to download the complete target version installation package. For large software (such as operating systems and industrial control programs), the installation package size often reaches several gigabytes, placing immense pressure on network bandwidth. In mobile networks or bandwidth-constrained scenarios, downloads can easily take hours and are prone to interruption due to network fluctuations, forcing users to start from scratch, severely impacting the user experience. Even when some solutions shift to incremental upgrades, their incremental package generation logic often relies on simple file comparisons, frequently containing redundant intermediate file differences, resulting in persistently high actual transmission volumes and failing to fully leverage the advantages of incremental upgrades.

[0003] More critically, the lack of data verification mechanisms exacerbates upgrade risks. Current solutions mostly perform a single verification after all data has been received. If data corruption or tampering is detected at this point, the entire upgrade package must be retransmitted. This is particularly problematic in industrial environments with unstable networks, potentially causing production systems to be stuck in an upgrade stalemate for extended periods. Furthermore, the lack of real-time fragment-level verification during transmission makes it difficult to detect lost or tampered data packets immediately. This can lead to terminals receiving erroneous data and using it in software synthesis, ultimately causing program crashes, functional abnormalities, or even system vulnerabilities. In addition, the lack of dynamic encryption and authentication during upgrade data transmission allows malicious third parties to intercept and tamper with upgrade packages, injecting malicious code. Terminals, lacking effective integrity verification methods, struggle to identify forged data, directly threatening software security and user data privacy. These issues collectively make software upgrades a weak link affecting system stability and user experience. Summary of the Invention

[0004] The main objective of this invention is to provide an online upgrade method and system for computer software, aiming to solve the problems of poor data accuracy and insufficient upgrade concealment in the traditional online upgrade process of computer software, and to provide an efficient, stable, secure and concealed online upgrade solution for computer software.

[0005] To achieve the above objectives, the present invention provides an online upgrade method for computer software, comprising the following steps: The terminal obtains the current version information and target version information returned by the server; The current version information and the target version information are compared to generate a version difference list, and the version difference list is sent to the server; the server generates an incremental upgrade package based on the version difference list, the incremental upgrade package is divided into multiple data shards, and the server sends the shard hash value and the target hash value of each data shard to the terminal; During the receiving process, each data fragment is verified. The verification content is whether the actual hash value of each data fragment is consistent with the corresponding fragment hash value sent by the server. If they are inconsistent, a retransmission request for the corresponding data fragment is sent to the server. After receiving all data fragments and verifying all data fragments, the data fragments are merged into a complete incremental upgrade package. The complete incremental upgrade package is then combined with the current version of the local software to obtain the combined software. The actual overall hash value of the synthesis software is calculated, and the actual overall hash value is compared with the target hash value sent by the server. If they match, the terminal completes the software upgrade.

[0006] Further, the step of comparing the current version information and the target version information to generate a version difference list includes: The current version information and target version information are parsed to obtain the module identifier and module version number of each functional module included in the current version, and the module identifier and module version number of each functional module included in the target version. Match each functional module in the current version with each functional module in the target version one by one according to the module identifier, and filter out functional modules with the same module identifier but different module version numbers, as well as functional modules that exist only in the current version and functional modules that exist only in the target version; For functional modules with the same module identifier but different module version numbers, extract the file change records within the functional module. The file change records include the paths of newly added files, the paths of deleted files, and the paths and content of modified files. Functional modules that only exist in the current version are marked as modules to be deleted, functional modules that only exist in the target version are marked as modules to be added, and functional modules with the same module identifier but different module version numbers are marked as modules to be modified, and the corresponding file change records are associated with them. The module identifiers of modules to be deleted, the module identifiers and contents of modules to be added, and the module identifiers and file change records of modules to be modified are summarized to form the version difference list.

[0007] Furthermore, the step of the server generating an incremental upgrade package based on the version difference list includes: The server receives the version difference list, parses the version difference list to obtain the module identifier of the module to be deleted, the module identifier and module content of the module to be added, and the module identifier and file change record of the module to be modified. The server calls the corresponding stored module file according to the module identifier of the module to be added, extracts the file fragments that need to be modified in the corresponding functional module according to the file change record of the module to be modified, and generates a deletion instruction according to the module identifier of the module to be deleted. The server encapsulates the called module files, extracted file fragments, and generated deletion instructions according to a preset format to form the incremental upgrade package.

[0008] Furthermore, the incremental upgrade package is divided into multiple data shards, and the step of the server sending the shard hash value and target hash value of each data shard to the terminal includes: The server evenly splits the incremental upgrade package according to a preset data volume, forming multiple data fragments of equal size; The server calculates the hash value of each data shard as the shard hash value, and calculates the overall hash value of the incremental upgrade package as the target hash value; The server organizes the hash values ​​of all data shards and the target hash value into a hash information list, and sends the hash information list to the terminal through the data transmission channel.

[0009] Furthermore, the step of verifying each data fragment during the receiving process includes: Start the data receiving process and receive each data fragment of the incremental upgrade package in sequence according to the transmission sequence number of the data fragment; During the process of receiving each data fragment, the received partial data is cached in real time. After the data fragment is fully received, the local hash algorithm is called to calculate the actual hash value of the cached complete data fragment. Extract the shard hash value corresponding to the current data shard from the list of stored hash information, and compare the actual hash value with the shard hash value bit by bit; If the comparison results are consistent, the terminal marks the data fragment as valid and stores it in a local temporary directory; If the comparison results are inconsistent, the terminal marks the data fragment as invalid and clears the corresponding cached data.

[0010] Furthermore, if the comparison result is inconsistent, a retransmission request for the corresponding data fragment is sent to the server. The step of the server retransmitting the data fragment after receiving the retransmission request includes: If the comparison results are inconsistent, the terminal records the transmission sequence number of the corresponding data fragment and generates a retransmission request containing the transmission sequence number. The retransmission request includes the actual hash value of the data fragment and the corresponding fragment hash value. A retransmission request is sent through a communication connection established with the server. After receiving the retransmission request, the server parses out the transmission sequence number of the data fragment. The server locates the corresponding target data fragment from the stored data fragments based on the transmission sequence number and repackages the target data fragment. The server resends the encapsulated target data fragments to the terminal through the original data transmission channel.

[0011] Further, after receiving all data fragments and verifying all data fragments, the steps of merging the data fragments into a complete incremental upgrade package, and then combining the complete incremental upgrade package with the current local software version to obtain the synthesized software include: Sort all data fragments according to their transmission sequence number; The sorted data fragments are then concatenated sequentially to form a complete incremental upgrade package, which is then stored in the local cache directory. Read the installation directory of the current version of the software on the local machine, parse the complete incremental upgrade package, and extract the module files to be added, the file fragments to be modified, and the module identifiers to be deleted. Copy the module file to be added to the installation directory, replace the content of the corresponding file in the installation directory with the file fragment to be modified, delete the corresponding module file in the installation directory according to the module identifier to be deleted, and complete the synthesis to obtain the synthesized software.

[0012] Further, the actual overall hash value of the synthesized software is calculated, and the actual overall hash value is compared with the target hash value sent by the server. If they match, the terminal completes the software upgrade step, including: Traverse all files of the synthesis software, and use the same hash algorithm as the server to perform overall calculation on the contents of all files of the synthesis software to obtain the actual overall hash value of the synthesis software. During the process of receiving incremental upgrade packages, real-time fluctuation data of the optical fiber transmission channel is collected synchronously, including uplink and downlink parameters. The optical fiber fluctuation data is XORed with the basic key pre-stored in the terminal to generate a dynamic hash verification key. The actual overall hash value is encrypted using the dynamic hash verification key to obtain the encrypted actual hash value. The target hash value is extracted from the encrypted target hash information sent by the server. The target hash value has been encrypted with the server-side dynamic key corresponding to the same fiber optic wave data. The terminal decrypts the target hash value using the dynamic hash verification key. The encrypted actual hash value is compared with the decryption target hash value. If they match, it is checked whether the acquisition timestamp of the fiber optic wave data and the hash value generation timestamp are within a preset synchronization window. If they are within the synchronization window, the synthesis software is moved to the local software installation directory to replace the current version of the software, and the software version information stored locally is updated to the target version information to complete the covert software upgrade.

[0013] Further, the step of performing an XOR operation between the fiber optic wave data and the pre-stored basic key in the terminal to generate a dynamic hash verification key includes: The collected fiber optic wave data is digitally processed to convert the instantaneous optical power value, transmission delay microvariable, and polarization state parameters into a binary data stream of preset length, thus obtaining the fiber optic wave binary data. Read the pre-stored basic key, which is a binary key of the same length as the binary data of the fiber optic wave; Perform a bitwise XOR operation between the fiber optic wave binary data and the basic key in the same bit order. That is, the result is 0 when all corresponding bits are 0 or all corresponding bits are 1, and the result is 1 when one corresponding bit is 0 and the other is 1. The binary result obtained by bitwise XOR operation is converted into a hexadecimal string and used as the dynamic hash verification key.

[0014] This invention proposes an online upgrade system for computer software, wherein the system executes the aforementioned online upgrade method for computer software, comprising: The terminal includes: The request sending module is used to send upgrade requests to the server; The version parsing module is used to receive and parse the current version information and target version information returned by the server, compare the two to generate a list of version differences; The difference sending module is used to send the version difference list to the server; The fragment receiving module is used to receive each data fragment of the incremental upgrade package sent by the server, as well as the corresponding fragment hash value and target hash value. The fragment verification module is used to verify each data fragment during the receiving process and generate a retransmission request when the verification is inconsistent. The retransmission processing module is used to send retransmission requests to the server and receive retransmitted data fragments; The synthesis module is used to merge all data fragments into a complete incremental upgrade package after receiving all data fragments and passing the verification. The incremental upgrade package is then combined with the current version of the local software to obtain the synthesized software. The hash comparison module is used to calculate the actual overall hash value of the synthesized software, compare it with the target hash value sent by the server, and complete the software upgrade when the comparison matches. The server includes: The request receiving module is used to receive upgrade requests sent by the terminal and return the current version information and target version information to the terminal. The incremental generation module is used to receive a list of version differences and generate an incremental upgrade package based on the list. The data sharding module is used to divide the incremental upgrade package into multiple data shards, calculate the shard hash value of each data shard and the target hash value of the incremental upgrade package, and send them to the terminal. The data fragment sending module is used to send each data fragment to the terminal and resend the corresponding target data fragment after receiving a retransmission request.

[0015] The online upgrade method and system for computer software provided by this invention have the following beneficial effects: This invention can reduce unnecessary data transmission and improve the efficiency of the upgrade process. Through the dual verification mechanism of fragmented hash verification and overall hash comparison, data errors in the transmission process can be detected in a timely manner and targeted retransmission can be performed, thereby improving the accuracy of upgrade data. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating an online upgrade method for computer software according to an embodiment of the present invention; Figure 2 This is a structural block diagram of an online upgrade system for computer software according to an embodiment of the present invention; The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0018] Reference Figure 1 This is a flowchart illustrating an online upgrade method for computer software proposed in this invention. The method includes: S1, the terminal obtains the current version information and target version information returned by the server; S2, compare the current version information and the target version information to generate a version difference list, and send the version difference list to the server; the server generates an incremental upgrade package based on the version difference list, the incremental upgrade package is divided into multiple data shards, and the server sends the shard hash value and target hash value of each data shard to the terminal; S3. During the receiving process, each data fragment is verified. The verification content is whether the actual hash value of each data fragment is consistent with the corresponding fragment hash value sent by the server. If they are inconsistent, a retransmission request for the corresponding data fragment is sent to the server. S4. After receiving all data fragments and verifying all data fragments, merge all the data fragments into a complete incremental upgrade package, and use the complete incremental upgrade package to synthesize with the local current version of the software to obtain the synthesized software. S5, calculate the actual overall hash value of the synthesis software, compare the actual overall hash value with the target hash value sent by the server, and if they match, the terminal completes the software upgrade.

[0019] In S1, the process of the terminal obtaining the current version information and target version information returned by the server begins with the upgrade detection program initiated by the terminal itself. This can be either manually triggered by the user in the software settings or automatically started by the software in the background at a preset cycle. The terminal sends an upgrade request to the server through a preset communication protocol, containing its own device identifier and the unique ID of the currently running software. The device identifier is used by the server to distinguish different terminal types, and the software ID corresponds to the full version repository of the software stored on the server.

[0020] Upon receiving a request, the server first matches all version records corresponding to the software ID in the version management database. Then, it locates the current version information based on the software version number currently running on the terminal, and simultaneously extracts the latest stable version of the software as the target version information. Both types of information exist in structured data format, such as version identifiers in the format "major version number.minor version number.revision number", names of each functional module and their corresponding compilation timestamps, and checksum summaries of core files.

[0021] The server encapsulates the current version information and the target version information into a response data packet and returns it to the terminal through the original communication link. After receiving the data packet, the terminal calls its local parsing program to decompose the structured data, separating key information such as the identification fields of the two versions, the module list, and the timestamp, and storing them in a temporary cache. The terminal can directly read the module list of the current version and the module list of the target version from the cache, thereby quickly identifying the differences between the two.

[0022] In one embodiment of S2, the step of comparing the current version information and the target version information to generate a version difference list includes: The current version information and target version information are parsed to obtain the module identifier and module version number of each functional module included in the current version, and the module identifier and module version number of each functional module included in the target version. Match each functional module in the current version with each functional module in the target version one by one according to the module identifier, and filter out functional modules with the same module identifier but different module version numbers, as well as functional modules that exist only in the current version and functional modules that exist only in the target version; For functional modules with the same module identifier but different module version numbers, extract the file change records within the functional module. The file change records include the paths of newly added files, the paths of deleted files, and the paths and content of modified files. Functional modules that only exist in the current version are marked as modules to be deleted, functional modules that only exist in the target version are marked as modules to be added, and functional modules with the same module identifier but different module version numbers are marked as modules to be modified, and the corresponding file change records are associated with them. The module identifiers of modules to be deleted, the module identifiers and contents of modules to be added, and the module identifiers and file change records of modules to be modified are summarized to form the version difference list.

[0023] Specifically, when parsing the current version information and the target version information, a preset version parser is invoked to extract all functional module information contained in the two types of versions from the structured data. Each functional module corresponds to a unique module identifier (e.g., "UI-001" represents the user interface module, and "DATA-002" represents the data processing module) and a specific module version number (e.g., "V2.1.3"). For example, after parsing the current version information, the module list is "UI-001: V2.1.3, DATA-002: V1.5.0", and after parsing the target version information, "UI-001: V2.2.0, DATA-002: V1.5.0, SEC-003: V1.0.0".

[0024] Subsequently, the terminal initiates a module matching process, comparing each module one by one using its identifier as the keyword: when "UI-001" exists in both versions but with different version numbers (V2.1.3 and V2.2.0), it is marked as a module to be modified; "DATA-002" has the same identifier and version number in both versions and is not included in the difference list; "SEC-003" exists only in the target version and is marked as a module to be added; if "TOOL-004: V3.0.0" exists in the current version but not in the target version, it is marked as a module to be deleted.

[0025] For the module "UI-001" to be modified, the terminal further extracts its file change records: by comparing the file directories of this module in the two versions, the path of the newly added "button.css" file, the path of the deleted "old_icon.png" file, and the code modifications in lines 120-150 of the "main.js" file are identified, and this information is associated with the module. Finally, the terminal integrates the identifier "TOOL-004" of the module to be deleted, the identifier "SEC-003" of the module to be added and its corresponding complete module file, and the modification record of the module "UI-001" and its associated file change records into a version difference list in a unified format. Each record in the list includes the module type (deleted / added / modified), identifier, and specific content.

[0026] In another embodiment of S2, the step of the server generating an incremental upgrade package based on the version difference list includes: The server receives the version difference list, parses the version difference list to obtain the module identifier of the module to be deleted, the module identifier and module content of the module to be added, and the module identifier and file change record of the module to be modified. The server calls the corresponding stored module file according to the module identifier of the module to be added, extracts the file fragments that need to be modified in the corresponding functional module according to the file change record of the module to be modified, and generates a deletion instruction according to the module identifier of the module to be deleted. The server encapsulates the called module files, extracted file fragments, and generated deletion instructions according to a preset format to form the incremental upgrade package.

[0027] Specifically, after receiving the version difference list sent by the terminal, the server starts the list parsing process and extracts key information through preset parsing rules: from the module type markers at the top of the list, it identifies the identifier "TOOL-004" of the module to be deleted, the identifier "SEC-003" of the module to be added and the accompanying module file metadata, and the module "UI-001" to be modified and the associated file change record details (including the paths of added and deleted files and the specific locations of modified fragments).

[0028] For the module to be added, "SEC-003", the server retrieves the module resource library stored internally based on its module identifier and calls the complete compressed file corresponding to the identifier (containing core files such as "verify.dll" and "certificate.json"). For the module to be modified, "UI-001", the server locates the base file of the module stored in its own memory based on the path information in the file change record, extracts the target code snippet from lines 120-150 of "main.js" according to the record, and packages the complete content of "button.css" and the deletion mark of "old_icon.png". For the module to be deleted, "TOOL-004", the server generates a deletion command containing the identifier, and the command includes the uninstallation path parameter of the module on the terminal.

[0029] Finally, the server encapsulates the upgrade package according to a preset format: a header of fixed bytes records the total number of modules (e.g., "3" represents 1 deletion, 1 addition, and 1 modification), followed by the sequential assembly of the complete file stream of the added module, the file fragment and path identifier of the module to be modified, and the instruction code of the module to be deleted. Each part is separated by a specific delimiter, and a package length check value is added at the end, ultimately forming a structured incremental upgrade package to ensure that the terminal can parse and execute the corresponding operation according to the corresponding format after receiving it.

[0030] Specifically, after the server receives the version difference list sent by the terminal, the entire processing revolves around "accurately extracting differences and efficiently encapsulating upgrade content," with clear and targeted implementation logic. First, the list parsing process locates key information through preset rules, such as quickly identifying "TOOL-004" to be deleted, "SEC-003" to be added, and "UI-001" to be modified from the header markers. This structured parsing ensures that no differences are missed, laying an accurate foundation for subsequent processing.

[0031] For different types of modules, the server adopts differentiated processing: For the newly added "SEC-003", the corresponding complete compressed file in the resource library is directly called to avoid regenerating the module content and save computing resources; for the modified "UI-001", the entire module is not transmitted, but only the modified fragments of lines 120-150 in "main.js" and the necessary content of "button.css" are extracted, and the deletion path of "old_icon.png" is marked. This "transmit only differences" method greatly reduces the amount of data transmitted; for the deleted "TOOL-004", an instruction containing the uninstallation path is generated to ensure that the terminal can accurately remove the old module and avoid residual files occupying space or interfering with new functions.

[0032] Finally, the server encapsulates this content in a fixed format. The header records the total number of modules to facilitate quick statistics for the terminal. Each part is distinguished by a specific delimiter to ensure no confusion during parsing. The packet length check value at the end further ensures the integrity of the upgrade package.

[0033] This approach is remarkably effective: compared to traditional full upgrades that require transmitting the entire software package (often several GB), this method only transmits the differences (such as in the case above, which may only require transmitting a few hundred KB of fragments and instructions), significantly reducing network bandwidth usage and transmission time; compared to simple incremental upgrades that may contain redundant intermediate files, this method, by accurately extracting modified fragments and explicit instructions, makes the upgrade package size more streamlined and improves transmission efficiency by more than 50%.

[0034] Compared with existing methods, the advantages are concentrated in three aspects: First, the difference extraction is more accurate, avoiding the transmission of unnecessary complete modules and reducing redundant data; second, the encapsulation format is structured, which can quickly identify each part of the content during terminal parsing and reduce the parsing error rate; third, the handling of deleted modules is more explicit, ensuring that old files are completely removed through instructions with paths, avoiding conflicts between new and old files, thereby improving the upgrade success rate and software operation stability.

[0035] In another embodiment of S2, the incremental upgrade package is divided into multiple data fragments, and the step of the server sending the fragment hash value and target hash value of each data fragment to the terminal includes: The server evenly splits the incremental upgrade package according to a preset data volume, forming multiple data fragments of equal size; The server calculates the hash value of each data shard as the shard hash value, and calculates the overall hash value of the incremental upgrade package as the target hash value; The server organizes the hash values ​​of all data shards and the target hash value into a hash information list, and sends the hash information list to the terminal through the data transmission channel.

[0036] Specifically, after generating the incremental upgrade package, the server initiates the fragmentation process: First, it reads the system's preset single fragment data size threshold (e.g., 1MB) and evenly splits the complete incremental upgrade package according to this threshold. Assuming the total size of the upgrade package is 4.5MB, it is split into 5 data fragments, with the first 4 fragments each being 1MB and the last fragment being 0.5MB (if the preset rule is "split according to actual size when less than the threshold"). Each fragment is assigned a unique transmission sequence number (e.g., 001 to 005) to identify the order.

[0037] Subsequently, the server calls a preset hash algorithm (such as SHA-256) to independently calculate the hash value for each data fragment: it reads the binary data of fragment 001 and generates a 64-bit hash value as its fragment hash value; the same logic is used to calculate the fragment hash values ​​of fragments 002 to 005 in sequence. At the same time, the server performs a global hash calculation on the complete incremental upgrade package before splitting, and the resulting hash value is used as the target hash value for the terminal to verify the integrity of the upgrade package after synthesis.

[0038] After completing the hash calculation, the server sorts all fragment hash values ​​by transmission sequence number and organizes them together with the target hash value into a hash information list. The first line of the list records the target hash value, and each subsequent line corresponds to the sequence number of a data fragment and its fragment hash value (e.g., "001: xxxx...xxx", "002: yyyy...yyy"). Finally, the server prioritizes sending this hash information list to the terminal through a dedicated data transmission channel (such as a TCP connection) established with the terminal, ensuring that the terminal has obtained all verification bases before receiving the data fragments, thus preparing for subsequent real-time fragment verification.

[0039] In one embodiment of S3, the step of verifying each data fragment during the receiving process includes: Start the data receiving process and receive each data fragment of the incremental upgrade package in sequence according to the transmission sequence number of the data fragment; During the process of receiving each data fragment, the received partial data is cached in real time. After the data fragment is fully received, the local hash algorithm is called to calculate the actual hash value of the cached complete data fragment. Extract the shard hash value corresponding to the current data shard from the list of stored hash information, and compare the actual hash value with the shard hash value bit by bit; If the comparison results are consistent, the terminal marks the data fragment as valid and stores it in a local temporary directory; If the comparison results are inconsistent, the terminal marks the data fragment as invalid and clears the corresponding cached data.

[0040] Specifically, after receiving the hash information list sent by the server, the terminal immediately starts a dedicated data receiving process. This process opens a dedicated network port on the local machine to listen for the server's fragment transmission requests and records the expected transmission order of each data fragment through a preset sequence number mapping table. For example, when the server sends fragments in the sequence number "001→002→003→004→005", the terminal process will first wait for the fragment with sequence number 001, and then trigger the receiving mechanism of fragment 002 after it is received, ensuring that the fragments are assembled in the original order.

[0041] During the reception of each data fragment, the terminal temporarily stores the real-time received binary data stream in a memory buffer. The buffer allocates an independent storage unit for each fragment to avoid data confusion between different fragments. When the fragment with sequence number 001 is fully received (i.e., the number of bytes received matches the server's preset fragment size), the terminal calls the locally integrated SHA-256 hash algorithm to calculate the complete data of that fragment in the buffer, generating a 64-bit actual hash value, such as "a3b7c9...f2d1".

[0042] Subsequently, the terminal searches for the fragment hash value "a3b7c9...f2d1" corresponding to sequence number "001" in the stored hash information list. It verifies the two hash values ​​using a character-by-character comparison algorithm: if every character matches, the fragment is considered transmitted correctly, marked as "valid," and moved from the memory cache to a local temporary directory (e.g., " / upgrade / temp / "), while the fragment reception status table is updated. If any character does not match (e.g., the 10th character of the actual hash value is "x" while the list shows "y"), the fragment is immediately marked as "invalid," and a cache cleanup function is called to release the corresponding memory space, preventing erroneous data from occupying storage resources and reserving cache capacity for possible subsequent retransmissions. The entire verification process is executed immediately after each fragment is received, ensuring that problematic fragments are quickly identified and preventing invalid data from entering the subsequent synthesis process.

[0043] In another embodiment of S3, if the comparison result is inconsistent, a retransmission request for the corresponding data fragment is sent to the server, and the server retransmits the data fragment after receiving the retransmission request, including: If the comparison results are inconsistent, the terminal records the transmission sequence number of the corresponding data fragment and generates a retransmission request containing the transmission sequence number. The retransmission request includes the actual hash value of the data fragment and the corresponding fragment hash value. A retransmission request is sent through a communication connection established with the server. After receiving the retransmission request, the server parses out the transmission sequence number of the data fragment. The server locates the corresponding target data fragment from the stored data fragments based on the transmission sequence number and repackages the target data fragment. The server resends the encapsulated target data fragments to the terminal through the original data transmission channel.

[0044] Specifically, when the terminal detects that the actual hash value of a data fragment is inconsistent with the fragment hash value (for example, the actual hash value of fragment with sequence number 003 is "d4e5f6...a2b3", while the corresponding value in the hash information list is "d4e5f7...a2b3"), the retransmission mechanism will be triggered immediately: the fragment verification module of the terminal automatically records the transmission sequence number "003" of the fragment and generates a structured retransmission request - the request header clearly marks the "retransmission type" and the sequence number "003", and the body of the request includes the actual hash value of the fragment and the corresponding fragment hash value, so that the server can quickly locate the cause of the difference (such as packet loss or data tampering).

[0045] After generating the request, the terminal sends the retransmission request through the established long connection with the server (such as a persistent communication link based on TCP) to avoid the delay caused by re-establishing the connection. After listening to the request, the server's fragment receiving module calls the parser to extract the transmission sequence number "003", and then locates the target data fragment with sequence number 003 in the locally stored fragment resource pool (which stores the original backups of all data fragments by sequence number index).

[0046] To ensure the accuracy of retransmitted data, the server re-encapsulates the target fragment: a new checksum header (containing the timestamp of this retransmission and the fragment length) is added before the fragment data, and a temporarily generated single checksum is appended to the end, forming a data packet with the same format as the initial transmission but carrying the latest checksum information. Finally, the server sends the re-encapsulated fragment 003 to the terminal through the original data transmission channel (i.e., the same network link as the initial transmission), ensuring that the terminal can perform secondary reception and verification through the same receiving process and checksum logic.

[0047] In S4, after receiving all data fragments and verifying all data fragments, the steps of merging the data fragments into a complete incremental upgrade package, and then combining the complete incremental upgrade package with the current local software version to obtain the synthesized software include: Sort all data fragments according to their transmission sequence number; The sorted data fragments are then concatenated sequentially to form a complete incremental upgrade package, which is then stored in the local cache directory. Read the installation directory of the current version of the software on the local machine, parse the complete incremental upgrade package, and extract the module files to be added, the file fragments to be modified, and the module identifiers to be deleted. Copy the module file to be added to the installation directory, replace the content of the corresponding file in the installation directory with the file fragment to be modified, delete the corresponding module file in the installation directory according to the module identifier to be deleted, and complete the synthesis to obtain the synthesized software.

[0048] Specifically, once the terminal confirms that all data fragments have been received and verified, it first initiates the fragment sorting mechanism: the terminal reads the metadata of all data fragments from the local temporary directory, extracts the transmission sequence number of each fragment (such as 001, 002 to 005), and arranges them in ascending order of sequence number using the built-in sorting algorithm to ensure that the fragment order is consistent with the original order when the server splits the data—for example, fragment number 001 corresponds to the beginning of the upgrade package, and 005 corresponds to the end, avoiding splicing errors caused by possible out-of-order transmission.

[0049] After sorting, the terminal calls a file concatenation tool to append the binary data of each fragment to a newly created blank file in sequence: first, it reads the complete data of fragment 001 and writes it to the file, then concatenates the data of fragment 002 to the end of it, until all fragments are processed, finally forming a complete file that is completely consistent with the original incremental upgrade package of the server, and stores it in the local cache directory (such as " / local / upgrade / cache / "). At the same time, a temporary file integrity marker is generated to prevent the file from being accidentally modified during subsequent parsing.

[0050] Subsequently, the terminal locates the installation directory of the current version of the software (e.g., " / program / files / software / ") and starts the upgrade package parser: according to the preset format of the incremental upgrade package, it parses out the module type identifier in the header, extracts the complete file set of the module to be added (e.g., "SEC-003") (including "verify.dll", "certificate.json", etc.), the code snippet of lines 120-150 of "main.js" and the complete content of "button.css" in the module to be modified (e.g., "UI-001"), and the identifier and corresponding installation path of the module to be deleted (e.g., "TOOL-004") (e.g., " / program / files / software / tool / ").

[0051] During the compositing phase, the terminal performs three types of operations based on the parsing results: First, it copies all files of the new module "SEC-003" to the "modules / " subdirectory under the installation directory, ensuring file permissions are consistent with existing modules. Second, for the module "UI-001" to be modified, it opens the "main.js" file in the installation directory, locates lines 120-150, replaces the original content with the new code snippet from the upgrade package, and simultaneously overwrites "button.css" to the corresponding path. Third, based on the identifier of the module "TOOL-004" to be deleted, it calls the system deletion function to remove all associated files and subdirectories in the installation directory. After all operations are completed, the terminal generates a compositing completion marker in the installation directory. At this point, the software is the compositing software that integrates the incremental upgrade content.

[0052] In one embodiment of S5, the step of calculating the actual overall hash value of the synthesized software, comparing the actual overall hash value with the target hash value sent by the server, and if they match, then the terminal completes the software upgrade, includes: Traverse all files of the synthesis software, and use the same hash algorithm as the server to perform overall calculation on the contents of all files of the synthesis software to obtain the actual overall hash value of the synthesis software. During the process of receiving incremental upgrade packages, real-time fluctuation data of the optical fiber transmission channel is collected synchronously, including uplink and downlink parameters. The optical fiber fluctuation data is XORed with the basic key pre-stored in the terminal to generate a dynamic hash verification key. The actual overall hash value is encrypted using the dynamic hash verification key to obtain the encrypted actual hash value. The target hash value is extracted from the encrypted target hash information sent by the server. The target hash value has been encrypted with the server-side dynamic key corresponding to the same fiber optic wave data. The terminal decrypts the target hash value using the dynamic hash verification key. The encrypted actual hash value is compared with the decryption target hash value. If they match, it is checked whether the acquisition timestamp of the fiber optic wave data and the hash value generation timestamp are within a preset synchronization window. If they are within the synchronization window, the synthesis software is moved to the local software installation directory to replace the current version of the software, and the software version information stored locally is updated to the target version information to complete the covert software upgrade.

[0053] Specifically, after receiving the synthesis software, the terminal first initiates the overall hash calculation process: It recursively scans all files in the directory containing the synthesis software (including nested files in subdirectories, such as " / temp / synthetic / modules / SEC-003 / verify.dll" and " / temp / synthetic / main.js") using a file traversal tool, determining the reading order according to a preset file path sorting rule (e.g., alphabetical order) to ensure consistency in the file sequence calculated each time. Then, it calls the same SHA-256 hash algorithm as the server, concatenating the binary content of all files sequentially into a continuous data stream. The terminal then performs an overall hash calculation on this data stream, generating a 64-bit actual overall hash value, such as "7e8f9a...2b3c4d", which serves as the basis for verifying the integrity of the synthesis software.

[0054] Throughout the process of receiving the incremental upgrade package, the terminal's built-in fiber optic data acquisition module works synchronously: it captures the uplink and downlink parameters of the fiber optic transmission channel in real time through the optical module interface, recording a set of data every 50 milliseconds to form a fiber optic fluctuation dataset containing timestamps. The terminal reads the pre-stored basic key (a binary key of the same length as the converted fiber optic fluctuation data, such as 256 bits) from the secure storage area, and performs a bitwise XOR operation between the digitized fiber optic fluctuation data (converted from analog to digital to a 256-bit binary stream) and the basic key—for example, if a bit of the fluctuation data is "1" and the corresponding bit of the key is "0", the result is "1"; if both are "1", the result is "0"—generating a dynamic hash verification key. This key is unique due to the real-time fluctuation of the fiber optic cable and is consistent with the key generated by the server based on fluctuation data from the same time period.

[0055] The terminal uses the generated dynamic hash verification key to perform symmetric encryption (such as AES-256 encryption) on the actual overall hash value, obtaining the encrypted actual hash value. Simultaneously, it extracts the ciphertext from the encrypted target hash information pre-sent by the server. This ciphertext is the result of the server encrypting the target hash value using its generated dynamic key (based on the same fiber optic wave data). The terminal decrypts this ciphertext using its local dynamic hash verification key, obtaining the decrypted target hash value.

[0056] Next, the terminal performs a string-by-string comparison between the encrypted actual hash value and the decryption target hash value. If the two are completely consistent, it then extracts the collection timestamp of the fiber optic fluctuation data (e.g., "2024-05-2014:30:05.123") and the server hash value generation timestamp (included in the encrypted target hash information), and checks whether the difference between the two is within the preset synchronization window (e.g., ±1 second) to ensure that the key generation is based on the fluctuation data of the same time period and avoids key mismatch caused by time offset.

[0057] If the above comparison and time check pass, the terminal performs the final upgrade operation: the synthesized software is moved from the temporary directory (e.g., " / temp / synthetic / ") to the local software installation directory (e.g., " / program / files / software / "), overwriting the original version files; the version information manager is called to update the version number in the registry and local configuration files (e.g., from "V2.3.1" to "V2.4.0"), and a hidden log containing the upgrade time, terminal identifier, and hash verification result is generated (the specific verification process is not shown to the user). This completes the entire covert software upgrade process, ensuring that the upgraded software is completely consistent with the server's expected target version and that the transmission process has not been tampered with.

[0058] In another embodiment of S5, the step of performing an XOR operation between the fiber optic wave data and the pre-stored basic key in the terminal to generate a dynamic hash verification key includes: The collected fiber optic wave data is digitally processed to convert the instantaneous optical power value, transmission delay microvariable, and polarization state parameters into a binary data stream of preset length, thus obtaining the fiber optic wave binary data. Read the pre-stored basic key, which is a binary key of the same length as the binary data of the fiber optic wave; Perform a bitwise XOR operation between the fiber optic wave binary data and the basic key in the same bit order. That is, the result is 0 when all corresponding bits are 0 or all corresponding bits are 1, and the result is 1 when one corresponding bit is 0 and the other is 1. The binary result obtained by bitwise XOR operation is converted into a hexadecimal string and used as the dynamic hash verification key.

[0059] Specifically, the process of generating a dynamic hash verification key by performing an XOR operation on the fiber optic fluctuation data and the basic key begins with the digital conversion of physical parameters: the fiber optic fluctuation data collected by the terminal includes instantaneous optical power values ​​(such as real-time measurements from -3dBm to +2dBm), transmission delay variables (such as fluctuation values ​​from 10μs to 50μs), and polarization state parameters (such as the phase difference between horizontal and vertical polarization). The terminal uses a built-in analog-to-digital converter to map these physical quantities into numerical ranges—for example, instantaneous optical power values ​​are converted to integers from 0 to 50 with an accuracy of 0.1dBm (corresponding to -3dBm to +2dBm), transmission delay variables are converted to integers from 0 to 40 with an accuracy of 1μs, and polarization state parameters are converted to integers from 0 to 314 with an accuracy of 0.01 radians. Subsequently, these integers are converted into binary numbers (e.g., the optical power value "25" is converted into "11001"), and zero-padding or truncation is performed according to a preset length (e.g., 256 bits). Finally, they are spliced ​​together to form a fixed-length optical fiber fluctuation binary data (e.g., 256 bits of "0100110...10110").

[0060] The terminal reads the pre-stored basic key from a secure storage area (such as a hardware encryption module or a read-only partition). This key is a fixed binary key written at the factory, and its length is strictly consistent with the binary data of the fiber optic wave (e.g., both are 256 bits), such as "1011001...01001". It is only temporarily loaded into memory during operation to avoid persistent exposure.

[0061] Entering the XOR operation stage, the terminal synchronously processes the fiber optic wave binary data and the basic key bit by bit: it compares the first bit of both; if both are "0" or both are "1", the first bit of the result is "0"; if one is "0" and the other is "1", the first bit of the result is "1". This process continues bit by bit until the 256th bit, forming a 256-bit binary operation result (e.g., "1110111...11100").

[0062] Finally, the terminal converts the binary result into hexadecimal groups of 4 bits each (e.g., "1010" corresponds to "a", "1111" corresponds to "f"). The 256-bit binary can be divided into 64 groups, which form a 64-bit hexadecimal string (e.g., "a7f3...d2c9"). This string is the dynamic hash verification key, which has both randomness (based on real-time fiber optic fluctuations) and uniqueness (bound to the basic key).

[0063] Reference Appendix Figure 2 This is a structural block diagram of an online computer software upgrade system proposed in this invention. The online computer software upgrade method of the system includes: The terminal includes: The request sending module is used to send upgrade requests to the server; The version parsing module is used to receive and parse the current version information and target version information returned by the server, compare the two to generate a list of version differences; The difference sending module is used to send the version difference list to the server; The fragment receiving module is used to receive each data fragment of the incremental upgrade package sent by the server, as well as the corresponding fragment hash value and target hash value. The fragment verification module is used to verify each data fragment during the receiving process and generate a retransmission request when the verification is inconsistent. The retransmission processing module is used to send retransmission requests to the server and receive retransmitted data fragments; The synthesis module is used to merge all data fragments into a complete incremental upgrade package after receiving all data fragments and passing the verification. The incremental upgrade package is then combined with the current version of the local software to obtain the synthesized software. The hash comparison module is used to calculate the actual overall hash value of the synthesized software, compare it with the target hash value sent by the server, and complete the software upgrade when the comparison matches. The server includes: The request receiving module is used to receive upgrade requests sent by the terminal and return the current version information and target version information to the terminal. The incremental generation module is used to receive a list of version differences and generate an incremental upgrade package based on the list. The data sharding module is used to divide the incremental upgrade package into multiple data shards, calculate the shard hash value of each data shard and the target hash value of the incremental upgrade package, and send them to the terminal. The data fragment sending module is used to send each data fragment to the terminal and resend the corresponding target data fragment after receiving a retransmission request.

[0064] In summary, after the terminal sends an upgrade request to the server, it receives and compares the current version with the target version information to generate a version difference list. The server then generates an incremental upgrade package and splits it into numbered data fragments, simultaneously sending the fragment hash value and the target hash value. The terminal receives the fragments sequentially, verifies the hash values ​​in real time, and requests retransmission if they are inconsistent. After receiving all valid fragments, it concatenates them into a complete incremental package and combines it with local software to obtain the synthesized software. The terminal calculates the actual overall hash value of the synthesized software, combines it with fiber optic fluctuation data and the basic key to generate a dynamic verification key, encrypts it, and compares it with the server's encrypted target hash value. If they match, the upgrade is complete. This method improves upgrade efficiency, accuracy, and security through incremental transmission, fragment verification, and dynamic key verification.

[0065] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. An online upgrade method of computer software, characterized by, The method comprises the following steps: The terminal acquires the current version information and the target version information returned by the server; The current version information and the target version information are compared to generate a version difference list, and the version difference list is sent to the server; The server generates an incremental upgrade package according to the version difference list, the incremental upgrade package is divided into multiple data shards, and the server sends the shard hash value and the target hash value of each data shard to the terminal; During the receiving process, the actual hash value of each data shard is checked to determine whether it is consistent with the corresponding shard hash value sent by the server, and if not, a retransmission request for the corresponding data shard is sent to the server; After receiving all the data shards and all the data shards are checked, the data shards are combined into a complete incremental upgrade package, the complete incremental upgrade package is combined with the local current version software to obtain a combined software; The actual overall hash value of the combined software is calculated, and the actual overall hash value is compared with the target hash value sent by the server, and if they are consistent, the terminal completes the software upgrade.

2. The method of online upgrade of computer software according to claim 1, wherein, The step of comparing the current version information and the target version information to generate a version difference list comprises: The current version information and the target version information are parsed to obtain the module identifier and the module version number of each functional module contained in the current version, and the module identifier and the module version number of each functional module contained in the target version; Each functional module of the current version and each functional module of the target version are matched one by one according to the module identifier, and functional modules with the same module identifier but different module version numbers, functional modules existing only in the current version, and functional modules existing only in the target version are screened out; For the functional modules with the same module identifier but different module version numbers, file change records in the functional modules are extracted, the file change records include the path of the added file, the path of the deleted file, and the path and modification content of the modified file; the functional modules existing only in the current version are marked as to-be-deleted modules, the functional modules existing only in the target version are marked as to-be-added modules, the functional modules with the same module identifier but different module version numbers are marked as to-be-modified modules, and the corresponding file change records are associated; The module identifier of the to-be-deleted module, the module identifier and the module content of the to-be-added module, and the module identifier and the file change record of the to-be-modified module are summarized to form the version difference list.

3. The method of online upgrade of computer software according to claim 1, wherein, The step of generating an incremental upgrade package according to the version difference list by the server comprises: The server receives the version difference list, parses the version difference list to obtain the module identifier of the to-be-deleted module, the module identifier and the module content of the to-be-added module, and the module identifier and the file change record of the to-be-modified module; The server calls the corresponding module file stored according to the module identifier of the to-be-added module, extracts the file segment to be modified in the corresponding functional module according to the file change record of the to-be-modified module, and generates a deletion instruction according to the module identifier of the to-be-deleted module; The server encapsulates the called module file, the extracted file segment and the generated deletion instruction in a preset format to form the incremental upgrade package.

4. The method of online upgrade of computer software according to claim 1, wherein, The incremental upgrade package is divided into multiple data segments, and the server sends the segment hash value and the target hash value of each data segment to the terminal, including: The server uniformly splits the incremental upgrade package by a preset data amount to form multiple data segments of equal size; The server calculates the hash value of each data segment as the segment hash value and calculates the overall hash value of the incremental upgrade package as the target hash value; The server collates the segment hash values of all data segments with the target hash value into a hash information list and sends the hash information list to the terminal through a data transmission channel.

5. The method of online upgrade of computer software according to claim 1, wherein, In the receiving process, the step of checking each data segment includes: Start a data receiving process and receive each data segment of the incremental upgrade package in sequence according to the transmission sequence number of the data segment; In the process of receiving each data segment, the received part of the data is cached in real time, and after the data segment is completely received, a local hash algorithm is called to calculate the complete cached data segment to obtain the actual hash value of the data segment; Extract the segment hash value corresponding to the current data segment from the stored hash information list, and compare the actual hash value with the segment hash value bit by bit; If the comparison result is consistent, the terminal marks the data segment as valid and stores it in the local temporary directory; If the comparison result is inconsistent, the terminal marks the data segment as invalid and clears the corresponding cache data.

6. The method of online upgrade of computer software according to claim 5, wherein, If the comparison result is inconsistent, the terminal records the transmission sequence number of the corresponding data segment and generates a retransmission request containing the transmission sequence number, and the actual hash value and the corresponding segment hash value of the data segment are attached to the retransmission request; Send the retransmission request through the communication connection established with the server, and the server receives the retransmission request to parse the transmission sequence number of the data segment; the server locates the corresponding target data segment from the stored data segments according to the transmission sequence number, and re-encapsulates the target data segment; The server re-sends the encapsulated target data segment to the terminal through the original data transmission channel. After receiving all data segments and all data segments are checked, the data segments are merged into a complete incremental upgrade package, and the complete incremental upgrade package is used to synthesize the local current version software to obtain the synthesized software, including:

7. The method of online upgrade of computer software according to claim 1, wherein, Sort all data segments according to the transmission sequence number of each data segment; Concatenate the sorted data segments in sequence to form a complete incremental upgrade package and store it in the local cache directory; Read the installation directory of the local current version software, parse the complete incremental upgrade package, and extract the to-be-added module file, the to-be-modified file segment and the to-be-deleted module identifier therein; ​ Copy the to-be-added module file to the installation directory, replace the content of the same position of the corresponding file in the installation directory with the to-be-modified file segment, delete the corresponding module file in the installation directory according to the to-be-deleted module identifier, and complete synthesis to obtain the synthesized software.

8. The method of online upgrade of computer software according to claim 1, wherein, An actual overall hash value of the synthesized software is calculated, and the actual overall hash value is compared with a target hash value sent by the server; if the actual overall hash value is consistent with the target hash value, the terminal completes the software upgrading steps, including: All files of the synthesized software are traversed, and a same hash algorithm as that of the server is called to calculate the content of all files of the synthesized software to obtain an actual overall hash value of the synthesized software; In the process of receiving the incremental upgrade package, real-time fluctuation data of the optical fiber transmission channel are synchronously collected, including uplink parameters and downlink parameters, the optical fiber fluctuation data are subjected to an exclusive OR operation with a basic secret key pre-stored in the terminal to generate a dynamic hash check secret key; The actual overall hash value is subjected to encryption processing by using the dynamic hash check secret key to obtain an encrypted actual hash value; A target hash value is extracted from the encrypted target hash information sent by the server, the target hash value has been encrypted by using a server-side dynamic secret key corresponding to the same optical fiber fluctuation data, and the terminal decrypts the target hash value by using the dynamic hash check secret key to obtain a decrypted target hash value; The encrypted actual hash value is compared with the decrypted target hash value; if the encrypted actual hash value is consistent with the decrypted target hash value, it is detected whether a collection time stamp of the optical fiber fluctuation data and a hash value generation time stamp are within a preset synchronization window; if the collection time stamp and the hash value generation time stamp are within the synchronization window, the synthesized software is moved to a local software installation directory to replace a current version software, and software version information pre-stored in the local terminal is updated to target version information, thereby completing the secret software upgrading.

9. The method of online upgrade of computer software according to claim 8, wherein, The step of generating the dynamic hash check secret key by performing an exclusive OR operation between the optical fiber fluctuation data and the basic secret key pre-stored in the terminal includes: The collected optical fiber fluctuation data are subjected to digital processing to convert optical power instantaneous values, transmission time delay micro-variables and polarization state parameters into binary data streams of a preset length to obtain optical fiber fluctuation binary data; The pre-stored basic secret key is read, the basic secret key being a binary secret key of the same length as the optical fiber fluctuation binary data; The optical fiber fluctuation binary data and the basic secret key are subjected to a bit-by-bit exclusive OR operation in the same bit sequence, that is, the result is 0 when the corresponding bits are both 0 or both 1, and the result is 1 when one of the corresponding bits is 0 and the other is 1; The binary result obtained by the bit-by-bit exclusive OR operation is converted into a hexadecimal string to serve as the dynamic hash check secret key.

10. An online upgrade system of computer software, characterized by, The system performs the online upgrading method of the computer software according to any one of claims 1-9, and the method includes: The terminal includes: A request sending module configured to send an upgrading request to the server; A version analysis module configured to receive and analyze current version information and target version information returned by the server, and compare the two to generate a version difference list; A difference sending module configured to send the version difference list to the server; A piece receiving module configured to receive each data piece of the incremental upgrade package sent by the server and corresponding piece hash values and a target hash value; A piece receiving module configured to receive each data piece of the incremental upgrade package sent by the server and corresponding piece hash values and a target hash value; The slice verification module is configured to verify each data slice during the receiving process, and generate a retransmission request when the verification is inconsistent. The retransmission processing module is configured to send the retransmission request to the server and receive the re-sent data slice. The synthesis module is configured to combine the data slices into a complete incremental upgrade package after receiving all the data slices and passing the verification, and synthesize the incremental upgrade package with the local current version software to obtain the synthesized software. The hash comparison module is configured to calculate the actual overall hash value of the synthesized software, compare the actual overall hash value with the target hash value sent by the server, and complete the software upgrade when the comparison is consistent. The server comprises: The request receiving module is configured to receive the upgrade request sent by the terminal, and return the current version information and the target version information to the terminal. The incremental generation module is configured to receive the version difference list, and generate the incremental upgrade package according to the list. The slice processing module is configured to divide the incremental upgrade package into multiple data slices, calculate the slice hash value of each data slice and the target hash value of the incremental upgrade package, and send them to the terminal. The slice sending module is configured to send each data slice to the terminal, and re-send the corresponding target data slice after receiving the retransmission request.

Images