A server and terminal device

Abstract

This application provides a server and a terminal device. By dividing the entries in the version iteration file into data blocks on the server side, calculating the hash value and offset information of each data block, and generating an iteration metadata file, the terminal device can accurately locate the changed data blocks based on the metadata file during updates. It only downloads the target entry block data and merges it with the locally unchanged entry block data to generate the target file, avoiding the bandwidth waste caused by the transmission of the entire file and effectively improving the file update efficiency.

Description

Technical Field

[0001] This application relates to the field of game update technology, and more particularly to a server and terminal device. Background Technology

[0002] With the rapid development of the gaming industry, the size of game resources developed using Unreal Engine (UE) is constantly increasing, especially for AAA games, where the total size of their package files often reaches several gigabytes or even tens of gigabytes. During game version iterations, how to efficiently distribute updated resource packages to users has become a key factor affecting user retention and operational costs.

[0003] Currently, the UE engine's game resource update solution uses a single asset file as the smallest update unit. The update content is determined by comparing the baked content of the old and new versions, generating a Pak file containing the update content, and mounting the Pak file at runtime and giving it higher priority to achieve the update.

[0004] However, these solutions cannot accurately locate the changed areas within the Pak file. When only a few bytes in the asset file change, the entire asset file still needs to be updated, resulting in wasted bandwidth and low update efficiency. Summary of the Invention

[0005] This application provides a server and terminal device that can perform fine-grained block management of entries within a file. By recording block information through a metadata file, it can accurately locate changed areas during updates and download only the changed data blocks, thereby solving the problem of low update efficiency caused by the inability to accurately locate changed areas within a file in the prior art.

[0006] In a first aspect, embodiments of this application provide a server, the server comprising: The processor is configured as follows: In response to game version iteration events, retrieve version iteration files; Based on the first preset data length, the first entry in the version iteration file is divided into data blocks to obtain at least one first entry block; Calculate the first entry block hash value and first entry block offset information for each first entry block, and calculate the iteration file hash value of the version iteration file; wherein, the first entry block offset information is used to indicate the relative position of the first entry block in the version iteration file; Write the hash value of the first entry block, the offset information of the first entry block, and the hash value of the iteration file into the iteration metadata template to obtain the iteration metadata file; wherein, the iteration metadata file is used to indicate the target entry block corresponding to the game version iteration event of the terminal device; Write the file information of the version iteration file and the iteration metadata file into the manifest file template to obtain the iteration manifest file; The iteration metadata file and the iteration manifest file are sent to the terminal device.

[0007] Secondly, embodiments of this application provide a terminal device, which includes: The controller is configured as follows: In response to an update trigger command, the system retrieves an iteration metadata file corresponding to a version iteration file from the server and a local metadata file corresponding to a local version file from local storage. The version iteration file includes a first entry, which comprises at least one first entry block. The version iteration metadata file includes the first entry block hash value, first entry block offset information, and a first resource path of the first entry block. The local version file includes a second entry, which comprises at least one second entry block. The local metadata file includes the second entry block hash value, second entry block offset information, and a second resource path of the second entry block. Based on the first resource path of the first entry block and the second resource path of the second entry block, an entry block to be compared is determined in the second entry block; wherein, the entry block to be compared is a second entry block having the same second resource path as the first resource path; Compare the hash value of the second entry block of the entry block to be compared with the hash value of the first entry block of the corresponding first entry block; If the hash value of the second entry block corresponding to the entry block to be compared is different from the hash value of the first entry block, the entry block to be compared is marked as the target entry block; Download the target entry block data of the target entry block from the server according to the target resource path of the target entry block; Based on the target entry block offset information of the target entry block and the second entry block offset information of the second entry block, the target entry block data and the second entry block data are written to the target file template to obtain the target file; wherein, the target file is used to update the target program loaded in the terminal device.

[0008] Thirdly, embodiments of this application provide a game file update method, applied to the server described in the first aspect, comprising: In response to game version iteration events, retrieve version iteration files; Based on the first preset data length, the first entry in the version iteration file is divided into data blocks to obtain at least one first entry block; Calculate the first entry block hash value and first entry block offset information for each first entry block, and calculate the iteration file hash value of the version iteration file; wherein, the first entry block offset information is used to indicate the relative position of the first entry block in the version iteration file; Write the hash value of the first entry block, the offset information of the first entry block, and the hash value of the iteration file into the iteration metadata template to obtain the iteration metadata file; wherein, the iteration metadata file is used to indicate the target entry block corresponding to the game version iteration event of the terminal device; Write the file information of the version iteration file and the iteration metadata file into the manifest file template to obtain the iteration manifest file; The iteration metadata file and the iteration manifest file are sent to the terminal device.

[0009] Fourthly, embodiments of this application provide a game file update method, applied to the terminal device described in the second aspect, comprising: In response to an update trigger command, the system retrieves an iteration metadata file corresponding to a version iteration file from the server and a local metadata file corresponding to a local version file from local storage. The version iteration file includes a first entry, which comprises at least one first entry block. The version iteration metadata file includes the first entry block hash value, first entry block offset information, and a first resource path of the first entry block. The local version file includes a second entry, which comprises at least one second entry block. The local metadata file includes the second entry block hash value, second entry block offset information, and a second resource path of the second entry block. Based on the first resource path of the first entry block and the second resource path of the second entry block, an entry block to be compared is determined in the second entry block; wherein, the entry block to be compared is a second entry block having the same second resource path as the first resource path; Compare the hash value of the second entry block of the entry block to be compared with the hash value of the first entry block of the corresponding first entry block; If the hash value of the second entry block corresponding to the entry block to be compared is different from the hash value of the first entry block, the entry block to be compared is marked as the target entry block; Download the target entry block data of the target entry block from the server according to the target resource path of the target entry block; Based on the target entry block offset information of the target entry block and the second entry block offset information of the second entry block, the target entry block data and the second entry block data are written to the target file template to obtain the target file; wherein, the target file is used to update the target program loaded in the terminal device.

[0010] In the technical solution provided in this application embodiment, by dividing the entries in the version iteration file into data blocks on the server side, calculating the hash value and offset information of each data block, and generating an iteration metadata file, the terminal device can accurately locate the changed data blocks based on the metadata file when updating, download only the target entry block data and merge it with the locally unchanged entry block data to generate the target file, avoiding the bandwidth waste caused by the transmission of the complete file and effectively improving the file update efficiency. Attached Figure Description

[0011] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A schematic diagram of the data structure of the manifest file provided in this application embodiment; Figure 2 This is a schematic diagram of the data structure of the metadata file provided in the embodiments of this application; Figure 3 This application provides a schematic diagram of the architecture of a file update system. Figure 4 A flowchart illustrating the overall process of server-side file update processing provided in this application embodiment; Figure 5 A flowchart illustrating the server-focused sorting and alignment of the first entry provided in this application embodiment; Figure 6 A flowchart for calculating the hash value of the first directory and the hash value of the iterative file on the server side is provided for embodiments of this application; Figure 7 A flowchart for merging tail entry blocks on the server side provided in this application embodiment; Figure 8 This is an overall flowchart of the terminal device-side file update method provided in the embodiments of this application; Figure 9 A flowchart illustrating how a terminal device obtains an iterative metadata file from a manifest file, as provided in this application embodiment; Figure 10 A flowchart illustrating the process of handling missing local metadata files on the terminal device side, provided in this application embodiment; Figure 11 A flowchart illustrating the verification process for downloaded entry block data on the terminal device side, as provided in this application embodiment; Figure 12 A flowchart illustrating the adaptive selection of download strategies on the terminal device side provided in this application embodiment; Figure 13This is a flowchart illustrating the final verification of the target file by the terminal device side, as provided in an embodiment of this application. Detailed Implementation

[0013] The embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following examples do not represent all embodiments consistent with this application.

[0014] With the rapid development of the gaming industry, the size of game resources developed using Unreal Engine (UE) is constantly increasing, especially for AAA games developed with the UE5 engine, where the total size of their Pak files (Package Files) often reaches several gigabytes or even tens of gigabytes. Existing UE engine game resource update solutions all use a single asset file as the smallest update unit, without managing entries within the Pak file in blocks. This makes it impossible to accurately locate the changed areas within the file. When only a few bytes change in an asset file, the entire asset file still needs to be updated, resulting in wasted bandwidth and low update efficiency.

[0015] To address the aforementioned issues, this application provides a file update method and system. This method enables fine-grained block management of entries in version iteration files. By recording the hash value and offset information of each data block through a metadata file, the changed data blocks can be accurately located by comparing the metadata files of the old and new versions during the update. Only the changed data blocks are downloaded and merged with the unchanged data locally to generate the target file. This solves the problem of bandwidth waste and low update efficiency caused by the inability to accurately locate the changed areas inside the file in the prior art, and effectively improves the file update efficiency.

[0016] To facilitate a clear description of the embodiments of this application, the terms defined in the embodiments of this application will be explained below with reference to the accompanying drawings.

[0017] Figure 1 This is a schematic diagram of the data structure of the manifest file provided in an embodiment of this application.

[0018] like Figure 1 As shown, the manifest file is used to manage all files of the corresponding program version. Taking a game program as an example, when the game version is iterated, the server can generate a corresponding manifest file to record the various types of files associated with this iteration and the key information of each type of file.

[0019] In some embodiments, the manifest file includes relative paths / resource paths, data lengths, and hash values ​​for ordinary binary files, Pak files, and metadata files (e.g., files with the .fymeta extension). It also includes key information from some files used to assist users in updating the game version, such as chunk information for Pak files. This chunk information can be constructed as an array, with array cells recording the identifiers of different chunks.

[0020] In this way, the server can send a manifest file to the client, informing the client of the files required for this game version iteration, as well as the corresponding verification information and key update-related information. The client can then obtain this information from the manifest file and update the game version according to the set verification and update procedures.

[0021] Figure 2 This is a schematic diagram of the data structure of the metadata file provided in the embodiments of this application.

[0022] like Figure 2 As shown, the number of metadata files corresponds one-to-one with the number of Pak files, and they are used to record the internal structure of the Pak files. In some embodiments, the metadata files include the mount point of the Pak file, entry information, block information, Pak Index area information (directory information corresponding to the Pak file), Pak file length, Pak file hash value, and Pak file encryption status.

[0023] The entry block information includes the offset value and data length of the entry block based on the entry division, as well as a list of entry blocks used to record multiple entry blocks.

[0024] In this way, the server sends metadata files to the client, and the client can compare the differences between the metadata files sent by the server and the local metadata files to determine whether it needs to download the target file for the update, and obtain the download path of the target file from the metadata files.

[0025] Figure 3 This is a schematic diagram of the architecture of a file update system provided in an embodiment of this disclosure. Figure 3 As shown, the file update system provided in this embodiment includes a server 100 and a terminal device 200.

[0026] Server 100 is used to respond to game version iteration events, preprocess the version iteration files, generate iteration metadata files and iteration manifest files, and send the above files to terminal device 200.

[0027] In some examples, server 100 may include a build-side tool module and a file distribution module. The build-side tool module is used to perform repackaging of the Pak file and generation of metadata files, while the file distribution module is used to distribute the iterative metadata file and iterative manifest file to the terminal device 200 through a content delivery network (CDN).

[0028] In some examples, the build-side tool module is built as an independent Program module based on the UE5 engine and compiled into a dynamic library, supporting multiple platforms such as Win64, Android, and iOS. The build-side tool module is responsible for scanning all Pak files in the target directory and performing a repackaging process for each Pak file, including reading the original Pak file, parsing Pak information, rearranging entries, handling alignment, rebuilding the directory, calculating block hashes, and other operations, ultimately generating Pak files adapted for incremental updates and corresponding metadata files.

[0029] The terminal device 200 receives the iterative metadata file and iterative manifest file from the server 100, performs difference calculations based on these files, determines the target entry blocks that need to be updated, downloads the target entry block data from the server 100, merges it with the locally unchanged entry block data to generate a target file, and updates the loaded target program based on the target file. In some examples, the terminal device 200 can be an electronic device with network communication and data processing capabilities, such as a personal computer, smartphone, tablet computer, or game console.

[0030] In some examples, the runtime update engine in terminal device 200 serves as a core module, responsible for core processes such as initialization, update task creation, difference calculation, data download and merging, and file writing. The runtime update engine exports interfaces to upper layers through dynamic libraries, including control interfaces for initialization, starting updates, pausing, resuming, retrying, and repairing, as well as network data callback interfaces for the upper network layer to return downloaded data.

[0031] In some examples, the file update system may also include an auxiliary tool module that provides general-purpose tools such as hash calculation, file reading and writing, and encryption to support the operation of various system modules. The auxiliary tool module decouples the network layer from the core logic, can flexibly connect to different HTTP / CDN implementations, and can adapt to different deployment environments without modifying the core code.

[0032] In some examples, server 100 and terminal device 200 communicate via wired or wireless network, with terminal device 200 retrieving files and data required for version iteration from server 100 via the network. Exemplary communication methods may include Ethernet, wireless fidelity (Wi-Fi), 4G, 5G, etc.

[0033] To facilitate the description of the embodiments of this application, the meanings and uses of some terms used in the embodiments of this application will be introduced below.

[0034] Version iteration file: A Pak file generated on the server side based on the UE engine and processed by reordering, alignment, etc., used to carry game resource entities. The version iteration file includes multiple first entries.

[0035] First entry: An independent resource unit in the version iteration file. Each first entry corresponds to an independent resource file in the game, such as textures or sound effects. Second entry: A resource entry in the client Pak file. The resource paths of corresponding first and second entries are the same; that is, the first resource path is the same as the second resource path.

[0036] First entry block: The smallest data block obtained by the server-side dividing the binary data of a single first entry according to a first preset length standard, which also serves as the smallest download unit for the user terminal in this embodiment. Second entry block: A local data block divided according to the same segmentation rules of the server-side, which is a data block that can be reused by the user terminal.

[0037] First entry block hash value: A hash digest calculated by the server from the complete binary data of a single first entry block, used to compare whether the resource fragment corresponding to the first entry block has undergone iteration. Second entry block hash value: Used by the client to compare and determine whether the resource fragment corresponding to the second entry block has undergone iteration.

[0038] First entry block offset information: Records the relative start and end byte positions of the first entry block within its parent entry, and is used by the user to determine the write position of the first entry block in the target file. Second entry block offset information: The relative position of the local second entry block within its parent entry, used to determine the write position of the second entry block in the target file.

[0039] First Resource Path: A unique virtual resource path bound to each first entry, used to match entries between old and new versions, and for the client to download the corresponding first entry from the server. Second Resource Path: A unique virtual resource path bound to each second entry, used to match entries between old and new versions.

[0040] First preset data length: The size of the data segmentation within a single first entry by the server, for example, 50MB, used to split the first entry into first entry blocks.

[0041] Second preset data length: The boundary size for alignment between the first entries, such as 4KB / 64KB, used to standardize the physical layout of the Pak file.

[0042] First directory: The Pak Index directory, located at the end of the version iteration file, is the native resource directory table in the UE engine. It is used to store the number of the first entries in the Pak file, resource paths, offset information, and version numbers, which can be used by the user to determine whether game resources have changed.

[0043] Iterative file hash value: After the server completes reordering, alignment, block division, and generation of the first directory, the overall hash of the complete and standardized version iterative file can be used as the basis for the user to finally verify the target file.

[0044] Iterative Metadata Template: A blank template containing multiple preset storage fields used to form an iterative metadata file.

[0045] Iterate through the metadata file; local metadata file: the specific structure can be found in the attached diagram and text description above.

[0046] Iteration metadata hash: The hash value of the complete binary data of the iteration metadata file, stored in the iteration manifest file, which the user can use to determine whether the local metadata file needs to be iterated.

[0047] The manifest file template is a blank template, with reserved file information for storing Pak, iteration metadata, etc., such as hash value and data length.

[0048] The iteration manifest file records global file information for version iteration files and iteration metadata files written by the server. The local manifest file records global file information for local Pak files and local metadata files. These have already been described with reference to the accompanying diagrams and will not be repeated here.

[0049] The item block to be compared: In this embodiment, the item block to be compared is selected from the second item block on the user side. The item to be compared is determined by the resource path corresponding to the item, and then the item block to be compared is determined to realize the judgment of whether the fragmented resource generates iteration.

[0050] Target entry block: The entry block to be compared where the hash comparison is inconsistent, indicating that the fragment resource has undergone iteration and the iterated data needs to be downloaded from the server.

[0051] Target entry block offset information: The offset information corresponding to the entry block that generates the iteration is included in the first entry block offset information of the first entry block.

[0052] Target entry block hash value: used by the user to verify the downloaded resource.

[0053] Target file template: A temporary Pak file carrier on the user's end, used to carry the mixed target entry block data written to the download and the second entry block data locally.

[0054] Target file: A version iteration file that can be used by the user client to update the game program, formed by merging local resource fragments with downloaded resource fragments.

[0055] Target file hash value: Used by the client to verify the target file after it is generated, to determine whether a complete and usable version iteration file for updating the game program has been generated.

[0056] It is understandable that game update scenarios usually involve other binary files besides the Pak file. Since these other binary files are not applicable to the technical solutions provided in this application, the download and verification process of these other binary files is not described. However, this does not mean that the game update scenario of this application will be executed without other binary files.

[0057] In some embodiments, based on the technical solutions provided in the embodiments of this application, a manifest file can be constructed by combining other binary files, but this process does not affect the technical solutions provided in the embodiments of this application. In the following embodiments, the improvements to the Pak file will be fully described.

[0058] Figure 4 This is an overall flowchart of the server-side file update processing method provided in this embodiment. This method can be executed by the server, corresponding to the overall server processing flow described in claim 1. The following is in conjunction with… Figure 4 An example is provided.

[0059] like Figure 4 As shown, in one embodiment, the method includes the following steps S110-S160: S110: Responds to game version iteration events and retrieves version iteration files.

[0060] In some examples, a game version iteration event refers to the event where the game program updates from the current version to a new version. When the game developers complete the development of the new version's resources, the version iteration event is triggered, and the server begins executing the file update preprocessing flow.

[0061] In some examples, after the server obtains the version iteration file, it can also perform a repackaging operation on the version iteration file through the build-side tool module, including rearranging the first item, handling alignment, rebuilding the directory, etc., to generate a standardized version iteration file adapted for incremental updates.

[0062] S120: Based on the first preset data length, perform data segmentation on the first entry in the version iteration file to obtain at least one first entry block.

[0063] In some examples, the first preset data length is the size standard by which the server divides the data within a single first entry, and is the smallest download unit granularity of the terminal device.

[0064] In some examples, the first preset data length can be set according to actual needs, such as 50MB.

[0065] In some examples, the server sequentially divides the binary data of each first entry into several first entry blocks, based on a first preset data length. Each first entry block contains a continuous segment of binary data from the first entry. By dividing the first entry into smaller data blocks, subsequent difference comparisons and incremental updates can be performed precisely at the block level, significantly reducing unnecessary data transfer.

[0066] The handling of the tail data block during the block division will be further explained in subsequent embodiments.

[0067] S130: Calculate the first entry block hash value and first entry block offset information for each first entry block, and calculate the iteration file hash value of the version iteration file.

[0068] In some examples, the first entry block hash is a hash digest calculated by the server from the complete binary data of a single first entry block. This hash is used to compare with the entry block hash on the terminal device side to determine whether the corresponding resource fragment has changed. In some examples, the first entry block hash can be calculated using a secure hash algorithm (SHA), such as the SHA1 algorithm.

[0069] In some examples, the first entry block offset information is used to record the relative start and end positions of the first entry block within its first entry, so that the terminal device can determine the write position of each data block when generating the target file.

[0070] In some examples, the iterative file hash value is the overall hash value calculated on the complete and standardized version of the iterative file after the server has completed reordering, alignment, chunking, and generated the first directory. This hash value is used by the terminal device for final verification after generating the target file. The calculation method of the iterative file hash value will be further explained in subsequent embodiments.

[0071] S140: Write the hash value of the first entry block, the offset information of the first entry block, the hash value of the first directory, and the hash value of the iterative metadata template to obtain the iterative metadata file.

[0072] In some examples, the iterative metadata template is a predefined blank template containing multiple preset storage fields, such as mount point field, entry information field, entry block information field, directory information field, file hash value field, and encryption identifier field. The server writes the block information and hash value calculated in steps S120 and S130 into the corresponding fields of the template in sequence, forming an iterative metadata file that corresponds one-to-one with the Pak file.

[0073] In some examples, the iteration metadata file is used to instruct the terminal device to determine the target entry block corresponding to the current game version iteration event, i.e., the data block that needs to be downloaded from the server.

[0074] In some examples, the iterative metadata file has the filename extension .fymeta, is stored in binary serialization with an appended check hash, and supports JSON export for debugging.

[0075] S150: Write the file information of the version iteration file and the iteration metadata file to the manifest file template to obtain the iteration manifest file.

[0076] In some examples, the manifest file template is a predefined blank template with fields reserved for storing file information such as Pak files and iterative metadata files. File information may include the relative path or resource path of the file, data length, hash value, etc.

[0077] In some examples, the manifest file also records the chunk information of the Pak file. That is, the directory (PakIndex) chunk information of the Pak file is constructed in the form of an array, and the array cells record the identifiers of different chunks.

[0078] S160: Send the iteration metadata file and iteration manifest file to the terminal device.

[0079] In some examples, the server sends iteration metadata files and iteration manifest files to the terminal device via CDN. After receiving the files, the terminal device initiates a local runtime update process.

[0080] In the technical solution provided by this disclosure, a version iteration file is obtained by responding to a game version iteration event. Based on a first preset data length, the entries are divided into data blocks. The hash value and offset information of each entry block are calculated, and the above information is written to the iteration metadata template to generate an iteration metadata file. Then, file information is written to the manifest file template to obtain an iteration manifest file. Finally, the above file is sent to the terminal device, so that the terminal device can accurately locate the changed area in the version iteration file based on the block information recorded in the metadata file, and only download the changed data blocks, avoiding the bandwidth waste caused by the transmission of the complete file and effectively improving the file update efficiency.

[0081] Figure 5 This is a flowchart of server-side sorting and alignment of the first item provided in an embodiment of this disclosure.

[0082] like Figure 5 As shown, in one embodiment, before step S120 above, that is, before performing data segmentation on the first entry based on the first preset data length, the method may further include the following steps S121-S122: S121: Reorder the first entry in the version iteration file based on the preset sorting rules.

[0083] In some examples, the default sorting rule refers to a sorting rule that ensures the order of the first entry after reordering is consistent with the order of the second entry in the local version file. By rearranging the first entry in the version iteration file on the server side in the same order as the local version file on the terminal device side, it ensures that entries with the same resource path in the old and new versions are in the same position in the file, thus enabling accurate matching of corresponding entries in subsequent difference comparisons.

[0084] In some examples, the default sorting rule is to sort by resource path. After parsing the original Pak file, the server sorts the entries according to their resource paths, ensuring that entries with the same resource paths are in the same relative position in both the old and new versions of the file.

[0085] S122: Align the first entry based on the second preset data length.

[0086] In some examples, the second preset data length is greater than the first preset data length, serving as the boundary size for alignment between the first entries, used to standardize the physical layout of the Pak file. In some examples, the second preset data length is 4KB or 64KB. By aligning the entries to their boundaries, the data layout on the storage medium becomes more regular, which is beneficial for subsequent data read / write efficiency and the stability of difference calculations.

[0087] In some examples, resource files with dependencies, such as .uasset and .uexp files, are arranged adjacently and aligned according to a second preset data length to ensure the continuity of related files of the same resource in physical storage.

[0088] After completing the above reordering and alignment operations, the offset information of the first entry block is calculated based on the aligned first entry. Since the entries have undergone reordering and alignment, their positions in the file have been standardized, making the offset information calculated based on the aligned entries more accurate and stable.

[0089] In the technical solution provided by this disclosure, by reordering and aligning the first entry before data block division, the entries with the same resource path in the old and new version files are kept in the same position in the file, and the physical layout of the data is more regular, thereby improving the accuracy and stability of subsequent difference calculation, avoiding misjudgment of differences due to inconsistent entry arrangement, and further improving the file update efficiency.

[0090] Figure 6 This is a flowchart of the server-side calculation of the hash value of the first directory and the hash value of the iterative file provided in this embodiment of the disclosure.

[0091] like Figure 6 As shown, in one embodiment, calculating the iteration file hash value of the version iteration file in step S130 above may include the following steps S131-S132: S131: Determine the hash value of the first directory based on the first data length of the first entry, the first entry block offset information, and the first resource path.

[0092] In some examples, the first directory corresponds to the version iteration file, recording one or more of the following: the number of first entries in the version iteration file, the resource path, the relative position, and the version number. The first directory hash value is calculated from the complete binary data of the first directory area. Because the first directory records metadata about the entry level, changes in the first directory hash value can reflect overall changes in the Pak file entry level.

[0093] S132: Calculate the hash value of the iterative file based on the first data length of the first entry, the block offset information of the first entry, and the hash value of the first directory.

[0094] In some examples, the iterative file hash value is calculated as a whole for the complete and standardized version of the iterative file, based on the first directory hash value and incorporating the data length and offset information of the first entry. Because the calculation of the iterative file hash value takes into account both the integrity of the entry data and the directory, it can serve as the basis for the terminal device to ultimately verify whether the target file is complete and usable.

[0095] In the technical solution provided by this disclosure, a multi-level hash verification system from the directory layer to the file layer is constructed by first determining the hash value of the first directory and then calculating the hash value of the iterative file. This enables the terminal device to perform multi-level verification after receiving the file, ensuring the integrity and correctness of the data and avoiding update failures caused by data transmission errors.

[0096] Figure 7 This is a flowchart of merging tail entries on the server side according to an embodiment of this disclosure.

[0097] like Figure 7 As shown, in one embodiment, when performing data segmentation on the first entry based on the first preset data length in step S120 above, the processing of the tail data block may include the following steps S123-S124: S123: Detect the amount of data in the last first entry block of the first entry.

[0098] After the server sequentially segments each first entry according to a first preset data length, a tail data block is naturally generated. The actual data size of this tail data block may be much smaller than the first preset data length. After segmenting each first entry, the server checks the actual data size of its last first entry block.

[0099] S124: If the data volume of the last first entry block is less than the preset data volume threshold, then the last first entry block will be merged into the previous entry block.

[0100] In some examples, the data size threshold is a preset threshold used to determine whether tail data blocks need to be merged. In some examples, the data size threshold can be set to 10% of a first preset data length, meaning that when the data size of the last entry block is less than 10% of the first preset data length, it is merged into the previous entry block.

[0101] By merging excessively small tail data blocks into the preceding entry block, the additional entry block management overhead caused by excessively small tail data blocks can be avoided. Each entry block needs to independently record its hash value, offset information, and other metadata in the iterative metadata file. Merging them reduces the number of entry blocks, optimizes the structure of the metadata file, and improves the efficiency of subsequent difference calculations.

[0102] In the technical solution provided by the embodiments of this disclosure, by detecting the data volume of the last entry block in the first entry and merging the tail data blocks that are less than the data volume threshold into the previous entry block, unnecessary metadata management overhead is avoided due to the tail data blocks being too small, thus optimizing the simplicity of the block structure and the efficiency of subsequent difference calculation.

[0103] Figure 8 This is an overall flowchart of the terminal device-side file update method provided in this embodiment of the disclosure. This method can be executed by the terminal device.

[0104] like Figure 8 As shown, in one embodiment, the method includes the following steps S210-S260: S210: In response to the update trigger command, obtain the local metadata file corresponding to the local version file and the iteration metadata file corresponding to the version iteration file.

[0105] In some examples, an update trigger command refers to an instruction that instructs a terminal device to execute a version update process. In some examples, the update trigger command can be manually triggered by the user, such as when the user clicks the update button in the game launcher. It can also be automatically triggered by the program when the game starts, for example, when the program detects a new version release on the server and automatically initiates an update.

[0106] In some examples, the local version file is the Pak file corresponding to the currently installed game version stored on the terminal device, including multiple second entries and second entry blocks. The local metadata file is a metadata file that corresponds one-to-one with the local version file, recording the hash value, offset information, and resource path of each second entry block. The iterative metadata file is the metadata file corresponding to the new version obtained from the server, recording the hash value, offset information, and resource path of each first entry block.

[0107] The method for obtaining the iterative metadata file in step S210 will be further explained in subsequent embodiments.

[0108] S220: Based on the first resource path of the first entry block and the second resource path of the second entry block, determine the entry block to be compared in the second entry block.

[0109] In some examples, the entry block to be compared is a second entry block with the same second resource path as the first entry block. Using the resource path as the matching key, corresponding entry blocks of the old and new versions can be accurately paired, providing a basis for subsequent hash value comparison.

[0110] In some examples, the terminal device iterates through all first entry blocks in the metadata file. For each first entry block, it searches for a second entry block with the same second resource path in the local metadata file using its first resource path. If found, the second entry block is identified as the entry block to be compared. If no second entry block with the same resource path is found, it means that the resource corresponding to the first entry block is a new resource, and the complete data needs to be downloaded from the server.

[0111] S230: Compare the hash value of the second entry block of the entry block to be compared with the hash value of the first entry block of the corresponding first entry block.

[0112] In some examples, the terminal device compares the hash value of the second entry block of the comparison entry block with the hash value of the first entry block of the corresponding first entry block recorded in the iterative metadata file. If the two hash values ​​are the same, it means that the data content of the entry block has not changed during the version iteration, and the terminal device can directly reuse the local second entry block data. If the two hash values ​​are different, it means that the data content of the entry block has changed and needs to be updated.

[0113] S240: If the hash value of the second entry block corresponding to the entry block to be compared is different from the hash value of the first entry block, mark the entry block to be compared as the target entry block.

[0114] In some examples, the target entry block refers to the entry block to be compared where the hash comparison is inconsistent, indicating that the corresponding resource fragment has changed in this version iteration and needs to be downloaded from the server. By performing hash comparisons on all entry blocks to be compared and marking the target entry block, the terminal device can generate a download list required for this update and only download the data blocks that have changed.

[0115] The selection of the download strategy after marking the target entry block in step S240 will be further explained in subsequent embodiments.

[0116] S250: Download the target entry block data from the server based on the target resource path of the target entry block.

[0117] In some examples, the terminal device determines the position of the target entry block in the version iteration file based on the first entry block offset information of the target entry block, and then requests the corresponding target entry block data from the server through the download interface provided by the server. The first entry block offset information includes the start and end byte positions of the target entry block in its respective first entry, and the terminal device can request to download data within a specified byte range.

[0118] The data verification after downloading in step S250 will be further explained in subsequent embodiments.

[0119] S260: Based on the target entry block offset information of the target entry block and the second entry block offset information of the second entry block, write the target entry block data and the second entry block data into the target file template to obtain the target file.

[0120] In some examples, the target file template serves as a temporary Pak file carrier on the user's end, used to hold the mixed download data and local data. The terminal device determines the write position of the downloaded data in the target file based on the first entry block offset information, and determines the write position of the unchanged local data in the target file based on the second entry block offset information. The downloaded target entry block data and the local second entry block data are then written to the corresponding positions in the target file template according to their respective offset information, resulting in the target file. The target file is used to update the target program loaded on the terminal device.

[0121] The final verification of the target file in step S260 will be further explained in subsequent embodiments.

[0122] In the technical solution provided by this disclosure, the terminal device obtains the iterative metadata file and the local metadata file, determines the entry block to be compared based on resource path matching, compares the hash values ​​item by item to find the target entry block that has changed, downloads only the target entry block data and merges it with the local unchanged data to generate the target file, thereby realizing accurate positioning and incremental update of the changed area inside the file, avoiding the bandwidth waste caused by the transmission of the complete file, and effectively improving the file update efficiency.

[0123] Figure 9 This is a flowchart illustrating how a terminal device obtains an iterative metadata file from a manifest file, as provided in this embodiment of the disclosure.

[0124] like Figure 9 As shown, in one embodiment, obtaining the local metadata file corresponding to the local version file and the iteration metadata file corresponding to the version iteration file in step S210 above may include the following steps S211-S213: S211: Obtain the iteration manifest file from the server and the local manifest file from local storage.

[0125] In some examples, the iterative manifest file is generated by the server during version iteration, recording global information about all files in this iteration, including the hash value, data length, and resource path of each file. The local manifest file is stored locally on the terminal device, recording global information about each file in the current local version. The manifest file is much smaller than the actual .pak and metadata files; therefore, by comparing the manifest files first, it's possible to quickly determine which metadata files need updating, reducing unnecessary file downloads.

[0126] In some examples, the manifest file can also be used to delete local metadata files and Pak files to directly clean up content that does not exist after the game update, thereby reducing unnecessary data comparisons and improving file update efficiency.

[0127] S212: Compare the iterative metadata hash in the iterative manifest file with the local metadata hash in the local manifest file.

[0128] The terminal device extracts the iteration metadata hash value from the iteration manifest file and the local metadata hash value from the local manifest file, and then compares the two byte by byte.

[0129] S213: If the iterative metadata hash value and the local metadata hash value are different, obtain the corresponding iterative metadata file from the server.

[0130] In some examples, if the iterative metadata hash value is the same as the local metadata hash value, it means that the server-side metadata file is consistent with the local metadata file, and the corresponding Pak file of the local metadata file has not changed. Therefore, there is no need to download the iterative metadata file, and the update process for that Pak file can be skipped. If they are different, it means that the corresponding Pak file may have changed, and the iterative metadata file needs to be downloaded for further detailed difference comparison.

[0131] In the technical solution provided by this disclosure, by first obtaining and comparing the metadata hash values ​​in the manifest file, the corresponding iterative metadata file is downloaded only when the hash values ​​are different. This achieves step-by-step filtering from the manifest file level to the metadata file level, avoids unnecessary file downloads, and further improves the efficiency of file updates.

[0132] Figure 10 This is a flowchart illustrating the process for handling missing local metadata files on the terminal device side, as provided in this embodiment of the disclosure.

[0133] like Figure 10 As shown, in one embodiment, when the terminal device fails to obtain the local metadata file in step S210 above, the following steps S214-S215 are executed: S214: If the local metadata file is not available, obtain the first resource path of all first entry blocks from the iterative metadata file.

[0134] In some examples, scenarios where the local metadata file is not obtained include: the terminal device is installing the game for the first time, and no metadata files for any historical versions exist locally; or the local metadata file is corrupted or lost due to disk failure, accidental deletion, or other reasons. In these scenarios, the terminal device cannot perform a hash comparison between the local and server-side entry blocks, so it needs to directly download all iteration data. The terminal device reads the first entry block offset information of all first entry blocks from the iteration metadata file and marks all first entry blocks as target entry blocks.

[0135] S215: Based on the first resource path of all first entry blocks, download the first entry block data of all first entry blocks from the server.

[0136] Based on the offset information of all first entry blocks obtained in step S214, the terminal device requests and downloads the binary data corresponding to each first entry block from the server one by one via the network. After the download is completed, all first entry block data is written into the target file template according to the offset information to generate the target file.

[0137] In some examples, the binary data corresponding to each first entry block can be requested from the server in parallel over the network to improve download efficiency.

[0138] The technical solution provided in this disclosure ensures the availability and fault tolerance of the file update process in the case of missing local metadata files by directly downloading all iterative data, avoiding update interruptions caused by missing local data and improving the stability of the system in various abnormal scenarios.

[0139] In some examples, embodiments of this application support resuming interrupted downloads to ensure file download efficiency.

[0140] Figure 11 This is a flowchart illustrating the verification process for downloaded entry block data on the terminal device side, as provided in this embodiment of the disclosure.

[0141] like Figure 11 As shown, in one embodiment, after downloading the target entry block data in step S250, the terminal device performs the following steps S251-S253 to verify the integrity of the downloaded data: S251: Calculate the target entry block hash value of the downloaded target entry block data.

[0142] The terminal device calculates the hash value of the target entry block using the same hash algorithm (such as SHA1 algorithm) as the server for the complete binary content of the target entry block data downloaded from the server, thus obtaining the target entry block hash value.

[0143] S252: Compare the target entry block hash value with the first entry block hash value recorded in the iterative metadata file.

[0144] The terminal device compares the calculated target entry block hash value with the corresponding first entry block hash value recorded in the iterative metadata file byte by byte.

[0145] S253: If the target entry block hash value is the same as the first entry block hash value recorded in the iterative metadata file, then based on the target entry block offset information of the target entry block and the second entry block offset information of the second entry block, the target entry block data and the second entry block data are written to the target file template to obtain the target file.

[0146] In some examples, if the target entry block hash value is the same as the first entry block hash value recorded in the iterative metadata file, it indicates that the downloaded data is complete and error-free, and the data has not been damaged or tampered with during transmission. At this point, the terminal device can write the target entry block data and the second entry block data to the target file template based on the target entry block offset information and the second entry block offset information, thereby obtaining the target file and continuing with subsequent steps.

[0147] S254: If the hash value of the target entry block is different from the hash value of the first entry block, it indicates that an error or corruption occurred during data transmission. In this case, the terminal device will re-download the target entry block data, i.e., return to step S250: re-initiate the download request.

[0148] In some examples, the terminal device can set a maximum number of retries to avoid infinite retries caused by persistent network problems.

[0149] In the technical solution provided by the embodiments of this disclosure, the integrity and correctness of the downloaded target entry block data are ensured by performing hash verification on the downloaded data. When the data verification fails, the data is automatically re-downloaded, which effectively prevents update failures caused by data transmission errors and improves the stability and reliability of the update process.

[0150] Figure 12 This is a flowchart of the adaptive download strategy selection on the terminal device side provided in this embodiment of the disclosure, corresponding to the adaptive download strategy described in claim 9.

[0151] like Figure 12 As shown, in one embodiment, after the terminal device marks the entry block to be compared as the target entry block in step S240, it performs the following steps S241-S244 to adaptively select a download strategy: S241: Get the first proportion of the target entry block in its first entry block.

[0152] In some examples, the first ratio refers to the proportion of the number or data volume of the target entry block to the total number or data volume of all entry blocks in the corresponding first entry block. The terminal device counts the number of entry blocks marked as target entry blocks in each first entry and divides that number by the total number of entry blocks in all entry blocks of that first entry to obtain the first ratio.

[0153] In some examples, the first proportion can also be calculated based on the amount of data, that is, the proportion of the total amount of data in the target entry block to the total amount of data in all entry blocks in the first entry.

[0154] In some examples, the first percentage threshold is a preset percentage value used to determine whether to use a block-based download strategy or a fine-grained block-based download strategy. The first percentage threshold can be configured according to the actual scenario, for example, set to 50% or 0.5.

[0155] S242: If the first ratio is greater than or equal to the first ratio threshold, download the first entry block data of the entire first entry block from the server based on the first entry block offset information of the first entry block.

[0156] When most data blocks in the first entry have changed (the first entry has a relatively high proportion of changes), if the block-by-block download method is still used, it will generate a large number of network requests and I / O operations, and the total overhead may actually exceed that of directly downloading the entire entry. Therefore, the terminal device downloads the complete binary data of the first entry from the server, completing the update with fewer requests and reducing the overhead of establishing and disconnecting network requests.

[0157] S243: If the first ratio is less than the first ratio threshold, download only the target entry block data of the target entry block from the server based on the target entry block offset information of the target entry block.

[0158] When only a small number of data blocks in the first entry have changed (the first proportion is low), the terminal device only downloads the data blocks marked as the target entry, minimizing bandwidth consumption and demonstrating the core advantage of incremental updates.

[0159] In the technical solution provided by the embodiments of this disclosure, the download strategy is adaptively selected according to the proportion of the target entry block in the first entry block. When there is a lot of changing data, whole block download is preferred to reduce the number of I / O operations. When there is less changing data, fine block download is preferred to reduce bandwidth consumption. This achieves a dynamic balance between download efficiency and bandwidth consumption, and further improves update efficiency.

[0160] Figure 13 This is a flowchart of the final verification of the target file by the terminal device side provided in this embodiment of the disclosure, corresponding to the target file hash verification process described in claim 10.

[0161] like Figure 13 As shown, in one embodiment, after the terminal device writes data to the target file template based on the target entry block offset information and the second entry block offset information to obtain the target file in step S260, the following steps S261-S262 are performed: S261: Calculate the target file hash value of the target file.

[0162] The terminal device calculates the hash value of the target file by using the same hash algorithm (such as SHA1 algorithm) as the server to calculate the complete binary data of the generated target file.

[0163] The terminal device compares the calculated target file hash value with the iterative file hash value calculated by the server when generating the iterative metadata file, byte by byte.

[0164] S262: If the target file hash value is the same as the iteration file hash value recorded in the iteration metadata file, update the target program loaded in the terminal device based on the target file.

[0165] When the hash value of the target file matches the hash value of the iterative file on the server, it indicates that no errors occurred during the target file generation process, the merged and written data is completely correct, and the target file is completely consistent with the standard version iterative file on the server. At this point, the terminal device can safely use the target file to replace the local old version of the program file, completing the update of the target program.

[0166] If the target file hash value is different from the iterative file hash value (not shown in the figure), it indicates that an anomaly has occurred during the file merging and writing process (such as an offset calculation error or a data write misalignment). The terminal device should discard the current target file and re-execute the update process, starting from step S210 to re-acquire the metadata file and re-calculate and download the difference.

[0167] In the technical solution provided by this disclosure, by performing overall hash verification on the generated target file and comparing it with the hash value of the iterative file recorded on the server, a complete verification link from the block level to the file level is constructed, ensuring that the updated target file is completely consistent with the standard version on the server, effectively preventing program abnormalities caused by file writing errors.

[0168] This application provides a game file update method, applied to a server, including: In response to game version iteration events, retrieve version iteration files; Based on the first preset data length, the first entry in the version iteration file is divided into data blocks to obtain at least one first entry block; Calculate the first entry block hash value and first entry block offset information for each first entry block, and calculate the iteration file hash value of the version iteration file; wherein, the first entry block offset information is used to indicate the relative position of the first entry block in the version iteration file; Write the hash value of the first entry block, the offset information of the first entry block, and the hash value of the iteration file into the iteration metadata template to obtain the iteration metadata file; wherein, the iteration metadata file is used to indicate the target entry block corresponding to the game version iteration event of the terminal device; Write the file information of the version iteration file and the iteration metadata file into the manifest file template to obtain the iteration manifest file; The iteration metadata file and the iteration manifest file are sent to the terminal device.

[0169] This application provides a game file update method, applied to a terminal device, including: In response to an update trigger command, the system retrieves an iteration metadata file corresponding to a version iteration file from the server and a local metadata file corresponding to a local version file from local storage; wherein, the version iteration file includes a first entry, the first entry including at least one first entry block; the version iteration metadata file includes a first entry block hash value, a first entry block offset information, and a first resource path of the first entry block; the local version file includes a second entry, the second entry including at least one second entry block; the local metadata file includes a second entry block hash value, a second entry block offset information, and a second resource path of the second entry block; Based on the first resource path of the first entry block and the second resource path of the second entry block, an entry block to be compared is determined in the second entry block; wherein, the entry block to be compared is a second entry block having the same second resource path as the first resource path; Compare the hash value of the second entry block of the entry block to be compared with the hash value of the first entry block of the corresponding first entry block; If the hash value of the second entry block corresponding to the entry block to be compared is different from the hash value of the first entry block, the entry block to be compared is marked as the target entry block; Download the target entry block data of the target entry block from the server according to the target resource path of the target entry block; Based on the target entry block offset information of the target entry block and the second entry block offset information of the second entry block, the target entry block data and the second entry block data are written to the target file template to obtain the target file; wherein, the target file is used to update the target program loaded in the terminal device.

[0170] Similar parts between the embodiments provided in this application can be referred to mutually. The specific implementation methods provided above are only a few examples under the overall concept of this application and do not constitute a limitation on the scope of protection of this application. For those skilled in the art, any other implementation methods extended from the solution of this application without creative effort shall fall within the scope of protection of this application.

Claims

1. A server, characterized by include: The processor is configured as follows: In response to game version iteration events, retrieve version iteration files; Based on the first preset data length, the first entry in the version iteration file is divided into data blocks to obtain at least one first entry block; Calculate the first entry block hash value and first entry block offset information for each first entry block, and calculate the iteration file hash value of the version iteration file; wherein, the first entry block offset information is used to indicate the relative position of the first entry block in the version iteration file; Write the hash value of the first entry block, the offset information of the first entry block, and the hash value of the iteration file into the iteration metadata template to obtain the iteration metadata file; wherein, the iteration metadata file is used to indicate the target entry block corresponding to the game version iteration event of the terminal device; Write the file information of the version iteration file and the iteration metadata file into the manifest file template to obtain the iteration manifest file; The iteration metadata file and the iteration manifest file are sent to the terminal device.

2. The server of claim 1, wherein, Before the processor performs data segmentation on the first entry in the version iteration file based on a first preset data length to obtain at least one first entry block, it is also configured to: Based on a preset sorting rule, the first entry in the version iteration file is reordered; wherein the order of the reordered first entry is the same as the order of the second file entries in the local version file; The first entry is aligned based on a second preset data length; wherein the second preset data length is greater than the first preset data length. Calculate the first entry block offset information of the first entry block based on the aligned first entry.

3. The server according to claim 2, characterized in that, The processor is specifically configured to calculate the iteration file hash value of the version iteration file as follows: The first directory hash value is determined based on the first data length of the first entry, the first entry block offset information, and the first resource path; wherein, the first directory hash value corresponds to the first directory, and the first directory is used to record one or more of the following in the version iteration file: the number of first entries, resource path, relative position, and version number; The iterative file hash value is calculated based on the first data length of the first entry, the first entry block offset information, and the first directory hash value.

4. The server according to claim 1, characterized in that, The processor performs data segmentation on the first entry in the version iteration file based on a preset data volume, obtaining at least one first entry block, specifically configured as follows: Detect the data volume of the last first entry block in the first entry; If the data volume of the last first entry block is less than the data volume threshold, then the last first entry block is merged into the previous entry block.

5. A terminal device, characterized in that, include: The controller is configured as follows: In response to an update trigger command, the system retrieves an iteration metadata file corresponding to a version iteration file from the server and a local metadata file corresponding to a local version file from local storage. The version iteration file includes a first entry, which comprises at least one first entry block. The version iteration metadata file includes the first entry block hash value, first entry block offset information, and a first resource path of the first entry block. The local version file includes a second entry, which comprises at least one second entry block. The local metadata file includes the second entry block hash value, second entry block offset information, and a second resource path of the second entry block. Based on the first resource path of the first entry block and the second resource path of the second entry block, an entry block to be compared is determined in the second entry block; wherein, the entry block to be compared is a second entry block having the same second resource path as the first resource path; Compare the hash value of the second entry block of the entry block to be compared with the hash value of the first entry block of the corresponding first entry block; If the hash value of the second entry block corresponding to the entry block to be compared is different from the hash value of the first entry block, the entry block to be compared is marked as the target entry block; Download the target entry block data of the target entry block from the server according to the target resource path of the target entry block; Based on the target entry block offset information of the target entry block and the second entry block offset information of the second entry block, the target entry block data and the second entry block data are written to the target file template to obtain the target file; wherein, the target file is used to update the target program loaded in the terminal device.

6. The terminal device according to claim 5, characterized in that, The controller executes an update trigger command in response to obtain the local metadata file corresponding to the local version file and the iteration metadata file corresponding to the version iteration file, specifically configured as follows: Obtain the iteration manifest file from the server, and obtain the local manifest file from the local storage; Compare the iteration metadata hash value in the iteration manifest file with the local metadata hash value in the local manifest file; If the iterative metadata hash value and the local metadata hash value are different, obtain the corresponding iterative metadata file from the server.

7. The terminal device according to claim 5 or 6, characterized in that, The controller, in response to an update trigger command, retrieves the iteration metadata file corresponding to the version iteration file from the server and the local metadata file corresponding to the local version file. It is also configured to: If the local metadata file is not obtained, the first resource path of all first entry blocks is obtained from the iterative metadata file; Based on the first resource path of all the first entry blocks, download the first entry block data of all the first entry blocks from the server.

8. The terminal device according to claim 5, characterized in that, The controller is also configured to: Calculate the target entry block hash value of the target entry block data; If the target entry block hash value is the same as the first entry block hash value recorded in the iterative metadata file, then based on the target entry block offset information of the target entry block and the second entry block offset information of the second entry block, the target entry block data and the second entry block data are written to the target file template to obtain the target file; If the target entry block hash value of the target entry block is different from the first entry block hash value, the first entry block offset information of the target entry block is downloaded again.

9. The terminal device according to claim 5, characterized in that, After the controller marks the entry block to be compared as the target entry block when the hash values ​​of the second entry block and the first entry block corresponding to the entry block to be compared are different, it is further configured to: Obtain the first proportion of the target entry block in the first entry block; If the first ratio is greater than or equal to the first ratio threshold, the first entry block data of the first entry block is downloaded from the server based on the first entry block offset information of the first entry block; If the first ratio is less than the first ratio threshold, the target entry block data of the target entry block is downloaded from the server based on the target entry block offset information of the target entry block.

10. The terminal device according to claim 5, characterized in that, The controller executes the first entry block offset information and the second entry block offset information based on the target entry block and the second entry block, and writes the target entry block data and the second entry block data to the target file template. After obtaining the target file, it is further configured as follows: Calculate the target file hash value of the target file; If the target file hash value is the same as the iterative file hash value recorded in the iterative metadata file, the target program loaded in the terminal device is updated based on the target file.

Images