CN117462961A - Non-stop game release method, system, equipment and medium - Google Patents
Non-stop game release method, system, equipment and medium Download PDFInfo
- Publication number
- CN117462961A CN117462961A CN202311437469.7A CN202311437469A CN117462961A CN 117462961 A CN117462961 A CN 117462961A CN 202311437469 A CN202311437469 A CN 202311437469A CN 117462961 A CN117462961 A CN 117462961A
- Authority
- CN
- China
- Prior art keywords
- game
- version
- file
- compatibility
- executable
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 61
- 238000012545 processing Methods 0.000 claims abstract description 30
- 238000012423 maintenance Methods 0.000 claims abstract description 9
- 230000006870 function Effects 0.000 claims description 43
- 238000012546 transfer Methods 0.000 claims description 12
- 238000004422 calculation algorithm Methods 0.000 claims description 11
- 230000006835 compression Effects 0.000 claims description 10
- 238000007906 compression Methods 0.000 claims description 10
- 238000004590 computer program Methods 0.000 claims description 3
- 238000007726 management method Methods 0.000 description 36
- 230000009286 beneficial effect Effects 0.000 description 6
- 230000006837 decompression Effects 0.000 description 6
- 238000004458 analytical method Methods 0.000 description 4
- 230000003068 static effect Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000007689 inspection Methods 0.000 description 2
- 238000010845 search algorithm Methods 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000010485 coping Effects 0.000 description 1
- 238000000354 decomposition reaction Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
- A63F13/70—Game security or game management aspects
- A63F13/77—Game security or game management aspects involving data related to game devices or game servers, e.g. configuration data, software version or amount of memory
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
- A63F13/70—Game security or game management aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The invention discloses a method, a system, equipment and a medium for issuing a game without stopping, and relates to the technical field of electronic games. The non-stop game distribution system includes: version management module, compatibility processing module and customer end management module. The version management module is used for version management and release of game files, the compatibility processing module is used for checking the compatibility degree between different versions of game files, and the client management module is used for updating and managing the client game versions. The game operation and maintenance personnel can conveniently manage the versions of the game, check the game files of different versions, judge the compatibility between the game files, ensure the compatibility after the update of the game, update the executable file of the game, avoid the game stop to cause the player to be unable to play, ensure the continuity and availability of the game, ensure the consistency of the game files of the client and the server, and provide good game experience.
Description
Technical Field
The invention belongs to the technical field of electronic games, and particularly relates to a method, a system, equipment and a medium for issuing a game without stopping.
Background
In existing game release techniques, version updates and releases of games often require downtime for maintenance, which can be inconvenient for the game operator and players. During the shutdown maintenance, the player cannot play the game normally, and the game operator cannot update the game content in real time.
There are some methods of updating without stopping the machine, but for complex software systems such as games, more accurate and safe processing is required. However, the existing non-stop update method has some disadvantages in coping with a complex software system such as a game, and is prone to problems of file transfer errors or file conflicts.
Accordingly, there is a need for a more accurate, safe, and efficient method of non-stop game distribution that addresses the problems presented in the prior art and provides a better game update and distribution experience.
Disclosure of Invention
The invention aims to overcome the defects in the prior art and is used for solving the technical problems of shutdown maintenance, compatibility and low updating efficiency in the prior art.
In order to achieve the above purpose, the present invention adopts the following technical scheme:
a non-stop game distribution system, comprising: the system comprises a version management module, a compatibility processing module and a client management module;
the version management module is used for version management and release of the game files;
the compatibility processing module is used for checking the compatibility degree between different versions of game files;
the client management module is used for updating and managing the client game version.
The invention also provides a non-stop game release method, which comprises a server processing flow and a client processing flow;
the processing flow of the server side comprises the following steps:
step S1: pushing the game file to a game release server by a game operation and maintenance personnel, and marking the game version information;
step S2: the version management module attaches version information to all game files by calling an operating system API according to the game version information marked by the game operation staff;
step S3: version management module realizes version management of different version information game files through a difference checking method, realizes increment release, and saves server bandwidth and disk resources;
step S4: the compatibility processing module checks game files of different versions through a compatibility checking method, and marks different compatibility degrees of old versions according to new versions;
the client processing flow is as follows:
step S5: the client management module runs on the client to update and check the game version;
step S6: the client management module acquires a configuration file patch from the server, executes the patch and updates the configuration file;
step S7: the client management module acquires a resource file from the server, places the resource file in a designated directory, and updates the resource file;
step S8: and updating the executable file of the game without stopping by using the executable file non-stop updating method.
Preferably, the game files include executable files, resource files, and configuration files.
Preferably, the different degrees of compatibility of the new version with the old version include forward compatibility and incompatibility.
Preferably, the differential inspection method comprises the following steps:
step S301: the method comprises the steps that file content is obtained, and a version management module obtains new version configuration file content and old version configuration file content by reading configuration compression files;
step S302: after the new version configuration file and the old version configuration file content are obtained, the file content is decomposed according to the format, so that comparison is facilitated;
step S303: after decomposing the content of the configuration file, the version management module uses a sequence searching algorithm to compare the configuration file of the new version with the configuration file of the old version line by line;
step S304: according to the result of the sequence searching algorithm, the version management module generates a series of patches describing the difference between the new version configuration file and the old version configuration file, wherein the patches comprise operations of inserting, deleting and modifying rows;
step S305: and realizing increment release through patches.
Further, the configuration compression and decompression method comprises the following specific steps:
compressing the content of the configuration file by using a general compression algorithm to reduce the occupation of storage space and improve transmission efficiency, and compressing the text file into a byte sequence; then, adding header information in the compressed byte sequence, wherein the header information comprises the type, the length, the catalog and the label of the original file; then, calculating a hash value for the byte sequence added with the header information, taking the byte sequence as input, and outputting the hash value with fixed length; then, adding the hash value to the rear end of the byte sequence, and storing the hash value as a binary file;
when decompression is performed, opening a binary file, reading head information, and then performing hash calculation on the residual byte sequence; then decompressing the residual byte sequence by using a general decompression algorithm to obtain the original configuration file content; then reading the hash value of the fixed length of the rear end of the byte sequence, comparing whether the hash value of the rear end is consistent with the calculated hash value, and if so, indicating that the configuration file is not changed; the original configuration file is output as decompressed output.
Further, the specific steps of the sequence searching algorithm are as follows:
for each row of content of the new version and the old version, as two sequences a and B, each sequence consisting of n elements;
creating a two-dimensional array, called L, with the size of (n+1) x (n+1);
l [ i ] [ j ] represents the length of the longest common subsequence between the first i elements of sequence A and the first j elements of sequence B;
initializing the values of the first row and the first column to 0, i.e., L [0] [ j ] =l [ i ] [0] =0, wherein 0< =i < =n, 0< =j < =n;
traversing the elements of sequence a row by row starting from the first row (i from 1 to n);
traversing elements of sequence B column by column (j from 1 to n) starting from the first column for each element A [ i ]; if A [ i ] is equal to B [ j ], then L [ i ] [ j ] is set to L [ i-1] [ j-1] +1;
the longest common subsequence length between the first i elements representing sequence a and the first j elements of sequence B is increased by 1;
if A [ i ] is not equal to B [ j ], then L [ i ] [ j ] is set to max (L [ i-1] [ j ], L [ i ] [ j-1 ]);
representing taking the greater value of the longest common subsequence length between the first i-1 elements of sequence A and the first j elements of sequence B, and the longest common subsequence length between the first i elements of sequence A and the first j-1 elements of sequence B;
after traversing the whole two-dimensional array, L [ n ] [ n ] is the length of the longest public subsequence between the sequence A and the sequence B;
to determine the specific content of the longest common subsequence, backtracking may be performed starting from Ln, based on the values of the L array. Specifically, if A [ i ] is equal to B [ j ] and L [ i ] [ j ] = L [ i-1] [ j-1] +1, then adding A [ i ] to the longest common subsequence, and then subtracting 1 from both i and j;
if A [ i ] is not equal to B [ j ] or L [ i ] is not equal to L [ i-1] j-1+1, comparing the values of L [ i-1] j and L [ i ] j-1], and selecting a direction corresponding to a larger value for backtracking;
through the steps, the length of the longest public subsequence between the sequence A and the sequence B is calculated, and the specific content of the longest public subsequence can be traced back, namely the same content in the new and old files.
Preferably, the compatibility checking method specifically comprises the following steps:
step S401: the compatibility processing module reads game executable files of the new version and the old version;
step S402: comparing the executable files of the two different versions, and checking the function calling convention between the executable files; the transfer mode of the calling instruction and the related parameters in disassembly is included;
the method comprises the following specific steps: firstly, opening two executable files by using a binary static analysis tool, and navigating to a function needing to be compared; comparing the functions of the two versions, and checking the disassembling code, the operand of the function call instruction and the use condition of a register; comparing function calling conventions, and comparing calling instructions in two versions and related parameter transfer modes of each function, and checking whether the function calling instructions in the two versions are identical and the parameter transfer modes are consistent or not;
common function calling conventions such as cdecl, stdcal, and fastcall;
when comparing the function call instruction, checking the type of the function call instruction, then comparing the operands of the function call instruction in the two versions, and finally comparing the addressing modes of the function call instruction, including absolute address and relative address;
comparing the parameter transfer mode, comparing the operation number of the function call instruction and the use condition of the register to determine the transfer mode of the parameter, then checking whether the parameter is transferred through the register or the stack, if the parameter is transferred through the stack, checking the use condition of the stack pointer register (such as ESP and RSP), and checking whether the use modes are consistent in the two versions;
then, the compatibility of the new version and the old version is judged:
if the two versions of function call instructions and parameter delivery modes are completely consistent, then they are compatible in the function call convention;
if the function calling conventions of the two versions are inconsistent, compatibility problems may exist, and the compatibility degree of the new version of the executable file is marked as incompatible;
step S403: comparing the two executable files with different versions and checking whether the definition and layout of the data structure between the two executable files are consistent;
first, two executable files are opened using a binary static analysis tool and navigated to a data structure.
Then, comparing the field number and field names of the data structures in the two versions, and checking whether the field numbers and the field names are consistent; then, comparing the data types of each field in the two versions, including integer type, floating point type, character type and pointer type, and checking whether the same field has the same data type; then, comparing the sizes of each field in the two versions, and checking whether the same field has the same size; then, comparing the order of the fields in the data structure, checking whether the same field has the same order in both versions; then, checking the alignment mode of the data structures, which is usually determined by the setting of the compiler, and checking whether the data structures in the two versions adopt the same alignment mode; finally, comparing nested structures, if the data structure contains nested substructures or pointers, the definition of the substructures needs to be compared recursively;
then, the compatibility of the new version and the old version is judged:
two versions of a data structure are compatible in terms of data structure layout if they are completely identical in definition and layout;
if the two versions of the data structure are defined or laid out inconsistent, then compatibility issues may exist, marking the new version of the executable as incompatible;
step S404: if the new version game executable and the old version game executable being compared are completely identical in the check of function calling conventions, data structure definitions and layouts, then the new version compatibility degree of this executable is marked as forward compatibility.
Preferably, the method for updating the executable file without stopping the machine comprises the following specific steps:
step S801: the client management module receives the new version executable file marked as incompatible by the compatibility processing module from the server;
step S802: annotating incompatible members within the executable file;
wherein, the members refer to functions, methods, classes, structures, etc. in the programming language;
for example, in Java, the @ TargetMethod custom annotation is used to modify incompatible members;
step S803: loading various members in the executable file into the memory;
for example, in Java, the steps loaded into memory are as follows:
reading a plurality of classes in the executable file by using a DexFile, and loading the executable file by using a DexFile.loadDex () function;
traversing each class, and loading class members in the executable file by using DexFile.loadclass ();
obtaining memory information of each member in the virtual machine;
step S804: injecting members with annotations into the memory;
for example, in Java, after obtaining the memory information of each member of the executable file in the virtual machine, if the member has an @ TargetMethod annotation, the memory address of the member in the virtual machine is obtained;
according to the source code of jni, all members are orderly arranged in the memory space of the virtual machine, and the memory addresses have no gaps, so that the memory address difference value of the front member and the rear member is calculated, the size of the previous member in the memory of the virtual machine can be obtained, and the memory size of all members can be obtained continuously;
then, the member with the @ TargetMethod annotation is subjected to memory copying and is injected into the executable file of the old version;
step S805: after the members with annotations are injected in the memory, the old version executable is replaced with the new version executable.
The invention also provides an electronic device, which comprises one or more processors and a storage device, wherein the storage device is used for storing one or more programs, and when the one or more programs are executed by the one or more processors, the electronic device realizes the non-stop game release method.
The present invention also provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor of a computer, causes the computer to execute the above-described non-stop game distribution method.
In summary, due to the adoption of the technical scheme, the beneficial effects of the invention are as follows:
1. the invention can realize the version management of the game files with different versions, only issue updated partial files, save the bandwidth of the server and disk resources, and can conveniently manage the version update of the game by the game operation and maintenance personnel through the version management module.
2. The invention checks the game files of different versions, marks the different compatibility degrees of the old version aiming at the new version, compares the game files of the new version and the old version, judges the compatibility between the new version and the old version, marks the compatibility degree of the game files of the new version as forward compatibility or incompatibility, ensures the updated compatibility of the game, and avoids the situation that the game cannot normally run or has errors.
3. According to the method, the executable file of the game is updated through the method for updating the executable file without stopping the game, so that the situation that a player cannot play the game due to stopping of the game is avoided, the continuity and the usability of the game are ensured, the consistency of the game files of the client and the server is ensured, and good game experience is provided.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 illustrates a block diagram of a non-stop game distribution system of the present invention;
FIG. 2 is a diagram showing the steps of a non-stop game distribution method of the present invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
Example 1
Referring to fig. 1, the present embodiment provides a non-stop game release system, including: version management module, compatibility processing module and customer end management module.
The version management module is used for managing and publishing the version of the game file, pushing the game file to a publishing server and attaching version information to the file.
The compatibility processing module is used for checking the compatibility degree between the game files of different versions, comparing the game files of the new version with the game files of the old version, and judging the compatibility between the game files of the new version and the game files of the old version.
The client management module is used for updating and managing the game version of the client, checking the updating condition of the game version, acquiring configuration file patches and resource files from the server to update the game files, and meanwhile, the client management module can also realize updating executable files of the game without stopping the machine to ensure the normal running of the game.
The beneficial effects of this embodiment are:
1. the version management of the game files with different versions of information is realized, only part of updated files can be released, the bandwidth and disk resources of a server are saved, and the game operation and maintenance personnel can conveniently manage the version update of the game through the version management module.
2. Checking game files of different versions, marking different compatibility degrees of old versions for new versions, comparing the new version with the old version game files, judging the compatibility between the new version and the old version game files, marking the compatibility degree of the new version game files as forward compatibility or incompatibility, ensuring the updated compatibility of the game, and avoiding the situation that the game cannot run normally or has errors.
3. By the method for updating the executable file without stopping the game, the executable file of the game is updated, the situation that the game cannot be played by a player due to stopping of the game is avoided, continuity and usability of the game are guaranteed, the consistency of the game files of the client and the server is guaranteed, and good game experience is provided.
Example 2
Referring to fig. 2, the embodiment provides a method for issuing a game without stopping, which includes a server processing flow and a client processing flow.
The server processing flow comprises the following steps:
step S1: pushing the game file to a game release server by a game operation and maintenance personnel, and marking the game version information;
the game file comprises an executable file, a resource file and a configuration file;
the executable file is a binary file with a highly complex internal structure; the resource file is a compressed coded file, and the configuration file is generally a text file;
step S2: the version management module attaches version information to all game files by calling an operating system API according to the game version information marked by the game operation staff;
for example, calling a system API on a Windows platform appends version information for a game file:
const wchar_t*filePath＝L"C:\\Path\\To\\File"；
SetFileAttributes(filePath,FILE_ATTRIBUTE_HIDDEN)；
modifying the attribute of the game file through a SetFileAttribute function, and attaching version information;
step S3: version management module realizes version management of different version information game files through a difference checking method, realizes increment release, and saves server bandwidth and disk resources;
step S4: the compatibility processing module checks game files of different versions through a compatibility checking method, and marks different compatibility degrees of old versions according to new versions;
wherein the different degrees of compatibility of the new version to the old version include forward compatibility and incompatibility;
forward compatibility means that an old version of game file can be compatible with a new version of game file, and the compatibility can ensure that a game user of an old version can interact with a game user of a new version without using a new function, and the game user does not need to be upgraded to the new version;
incompatibility means that there is an unresolved conflict between the old version game file and the new version game file, resulting in that they cannot interact or interoperate, in which case, when there is a release of the new version of the incompatible game file, the player must be forced to update the new version;
the other part, the client processing flow of the non-stop game release method is as follows:
step S5: the client management module runs on the client to update and check the game version;
step S6: the client management module acquires a configuration file patch from the server, executes the patch and updates the configuration file;
step S7: the client management module acquires a resource file from the server, places the resource file in a designated directory, and updates the resource file;
step S8: and updating the executable file of the game without stopping by using the executable file non-stop updating method.
The beneficial effects of this embodiment are:
1. version management of game files with different versions is realized, only updated partial files can be released, and the bandwidth and disk resources of a server are saved.
2. And checking game files of different versions, marking different compatibility degrees of old versions according to new versions, ensuring compatibility of updated games, and avoiding situations that the games cannot normally run or have errors.
3. By the method for updating the executable file without stopping the game, the executable file of the game is updated, so that the situation that the game cannot be played by a player due to stopping of the game is avoided, and the continuity and the availability of the game are ensured.
Example 3
The embodiment further provides a method for checking the difference on the basis of embodiment 2, wherein different steps of checking the difference are adopted for different types of game files, and the types of the game files comprise executable files, resource files and configuration files.
The resource file includes various code files such as animation and music, and the executable file is binary file, so that the possibility of incremental release is not possessed, and the resource file is not subjected to differential inspection.
Incremental publishing refers to publishing only the changed file or the changed portion of the file, rather than publishing the entire file in its entirety.
Because of the binary files such as the animation, music and the like, and the executable files, the internal structure is highly complex, the modification performed in the files can affect the whole files, so that the file structure is destroyed, and the files cannot be normally played, and the resource files and the executable files are usually required to be completely released.
For the configuration file, the difference checking method comprises the following steps:
step S301: the method comprises the steps that file content is obtained, and a version management module obtains new version configuration file content and old version configuration file content by reading configuration compression files;
during compression, a configuration compression file is generated through a configuration compression method and is used for efficiently storing and retrieving the configuration file, and the configuration compression and decompression method comprises the following specific steps:
compressing the content of the configuration file by using a general compression algorithm to reduce the occupation of storage space and improve transmission efficiency, and compressing the text file into a byte sequence; then, adding header information in the compressed byte sequence, wherein the header information comprises the type, the length, the catalog and the label of the original file; then, calculating a hash value for the byte sequence added with the header information, taking the byte sequence as input, and outputting the hash value with fixed length; then, adding the hash value to the rear end of the byte sequence, and storing the hash value as a binary file;
when decompression is performed, opening a binary file, reading head information, and then performing hash calculation on the residual byte sequence; then decompressing the residual byte sequence by using a general decompression algorithm to obtain the original configuration file content; then reading the hash value of the fixed length of the rear end of the byte sequence, comparing whether the hash value of the rear end is consistent with the calculated hash value, and if so, indicating that the configuration file is not changed; the original configuration file is output as decompressed output.
Step S302: after the new version configuration file and the old version configuration file content are obtained, the file content is decomposed according to the format, so that comparison is facilitated;
wherein the format referred to by the format decomposition has a plurality of possibilities, for example, the file content is decomposed by rows;
step S303: after decomposing the content of the configuration file, the version management module uses a sequence searching algorithm to compare the configuration file of the new version with the configuration file of the old version line by line;
there are various implementations of the sequence search algorithm, for example, the specific steps of the sequence search algorithm are as follows:
for each row of content of the new version and the old version, as two sequences a and B, each sequence consisting of n elements;
creating a two-dimensional array, called L, with the size of (n+1) x (n+1);
l [ i ] [ j ] represents the length of the longest common subsequence between the first i elements of sequence A and the first j elements of sequence B;
initializing the values of the first row and the first column to 0, i.e., L [0] [ j ] =l [ i ] [0] =0, wherein 0< =i < =n, 0< =j < =n;
traversing the elements of sequence a row by row starting from the first row (i from 1 to n);
traversing elements of sequence B column by column (j from 1 to n) starting from the first column for each element A [ i ]; if A [ i ] is equal to B [ j ], then L [ i ] [ j ] is set to L [ i-1] [ j-1] +1;
the longest common subsequence length between the first i elements representing sequence a and the first j elements of sequence B is increased by 1;
if A [ i ] is not equal to B [ j ], then L [ i ] [ j ] is set to max (L [ i-1] [ j ], L [ i ] [ j-1 ]);
representing taking the greater value of the longest common subsequence length between the first i-1 elements of sequence A and the first j elements of sequence B, and the longest common subsequence length between the first i elements of sequence A and the first j-1 elements of sequence B;
after traversing the whole two-dimensional array, L [ n ] [ n ] is the length of the longest public subsequence between the sequence A and the sequence B;
to determine the specific content of the longest common subsequence, backtracking may be performed starting from Ln, based on the values of the L array. Specifically, if A [ i ] is equal to B [ j ] and L [ i ] [ j ] = L [ i-1] [ j-1] +1, then adding A [ i ] to the longest common subsequence, and then subtracting 1 from both i and j;
if A [ i ] is not equal to B [ j ] or L [ i ] is not equal to L [ i-1] j-1+1, comparing the values of L [ i-1] j and L [ i ] j-1], and selecting a direction corresponding to a larger value for backtracking;
through the steps, the length of the longest public subsequence between the sequence A and the sequence B is calculated, and the specific content of the longest public subsequence can be traced back, namely the same content in the new and old files;
step S304: according to the result of the sequence searching algorithm, the version management module generates a series of patches describing the difference between the new version configuration file and the old version configuration file, wherein the patches comprise operations of inserting, deleting and modifying rows;
step S305: incremental release is realized through patches;
after the patch is obtained, the patch is applied on the basis of the old version configuration file without completely releasing the new version configuration file, so that the old version configuration file can be converted into the new version configuration file, and the bandwidth and disk resources of a server are saved.
The present embodiment also provides a compatibility checking method on the basis of embodiment 2. Where compatibility generally refers to compatibility of executable files in a game file.
The compatibility checking method comprises the following specific steps:
step S401: the compatibility processing module reads game executable files of the new version and the old version;
step S402: comparing the executable files of the two different versions, and checking the function calling convention between the executable files; the transfer mode of the calling instruction and the related parameters in disassembly is included;
the method comprises the following specific steps: firstly, opening two executable files by using a binary static analysis tool, and navigating to a function needing to be compared; comparing the functions of the two versions, and checking the disassembling code, the operand of the function call instruction and the use condition of a register; comparing function calling conventions, and comparing calling instructions in two versions and related parameter transfer modes of each function, and checking whether the function calling instructions in the two versions are identical and the parameter transfer modes are consistent or not;
common function calling conventions such as cdecl, stdcal, and fastcall;
when comparing the function call instruction, checking the type of the function call instruction, then comparing the operands of the function call instruction in the two versions, and finally comparing the addressing modes of the function call instruction, including absolute address and relative address;
comparing the parameter transfer mode, comparing the operation number of the function call instruction and the use condition of the register to determine the transfer mode of the parameter, then checking whether the parameter is transferred through the register or the stack, if the parameter is transferred through the stack, checking the use condition of the stack pointer register (such as ESP and RSP), and checking whether the use modes are consistent in the two versions;
then, the compatibility of the new version and the old version is judged:
if the two versions of function call instructions and parameter delivery modes are completely consistent, then they are compatible in the function call convention;
if the function calling conventions of the two versions are inconsistent, compatibility problems may exist, and the compatibility degree of the new version of the executable file is marked as incompatible;
step S403: comparing the two executable files with different versions and checking whether the definition and layout of the data structure between the two executable files are consistent;
first, two executable files are opened using a binary static analysis tool and navigated to a data structure.
Then, comparing the field number and field names of the data structures in the two versions, and checking whether the field numbers and the field names are consistent; then, comparing the data types of each field in the two versions, including integer type, floating point type, character type and pointer type, and checking whether the same field has the same data type; then, comparing the sizes of each field in the two versions, and checking whether the same field has the same size; then, comparing the order of the fields in the data structure, checking whether the same field has the same order in both versions; then, checking the alignment mode of the data structures, which is usually determined by the setting of the compiler, and checking whether the data structures in the two versions adopt the same alignment mode; finally, comparing nested structures, if the data structure contains nested substructures or pointers, the definition of the substructures needs to be compared recursively;
then, the compatibility of the new version and the old version is judged:
two versions of a data structure are compatible in terms of data structure layout if they are completely identical in definition and layout;
if the two versions of the data structure are defined or laid out inconsistent, then compatibility issues may exist, marking the new version of the executable as incompatible;
step S404: if the new version game executable and the old version game executable being compared are completely identical in the check of function calling conventions, data structure definitions and layouts, then the new version compatibility degree of this executable is marked as forward compatibility.
The embodiment also provides a method for updating the executable file without stopping the machine on the basis of the embodiment 2, which comprises the following specific steps:
step S801: the client management module receives the new version executable file marked as incompatible by the compatibility processing module from the server;
step S802: annotating incompatible members within the executable file;
wherein, the members refer to functions, methods, classes, structures, etc. in the programming language;
for example, in Java, the @ TargetMethod custom annotation is used to modify incompatible members;
step S803: loading various members in the executable file into the memory;
for example, in Java, the steps loaded into memory are as follows:
reading a plurality of classes in the executable file by using a DexFile, and loading the executable file by using a DexFile.loadDex () function;
traversing each class, and loading class members in the executable file by using DexFile.loadclass ();
obtaining memory information of each member in the virtual machine;
step S804: injecting members with annotations into the memory;
for example, in Java, after obtaining the memory information of each member of the executable file in the virtual machine, if the member has an @ TargetMethod annotation, the memory address of the member in the virtual machine is obtained;
according to the source code of jni, all members are orderly arranged in the memory space of the virtual machine, and the memory addresses have no gaps, so that the memory address difference value of the front member and the rear member is calculated, the size of the previous member in the memory of the virtual machine can be obtained, and the memory size of all members can be obtained continuously;
then, the member with the @ TargetMethod annotation is subjected to memory copying and is injected into the executable file of the old version;
step S805: after the members with annotations are injected in the memory, the old version executable is replaced with the new version executable.
The embodiment has the beneficial effects that by using the difference checking method: only comparing the difference between the new version configuration file and the old version configuration file by the difference checking method, the file size to be transmitted can be reduced, and the bandwidth and disk resources of the server are saved; by comparing the differences between the new and old versions of configuration files, the version management module can generate a series of patches describing the differences, so that when a game is updated, only the patch files are required to be transmitted, the whole configuration file is not required to be retransmitted, incremental release is realized, the updating time of a client can be reduced, and the experience of a player is improved.
The embodiment has the beneficial effects that by using the compatibility checking method: by comparing function calling conventions, data structure definitions and layouts of the game executable files of the new and old versions, compatibility between the two versions can be determined, if the two versions are completely consistent in the aspects, normal running of the game after updating is ensured, the problems of game errors, abnormal or breakdown caused by incompatibility are avoided, and stability and reliability of the game are improved.
The method for updating the executable file without stopping the machine has the beneficial effects that: the method has the advantages that the executable file can be updated while the game server runs, the game server is prevented from being stopped, the game experience of a player is not affected, the continuity and the usability of the game are ensured, the performance and the experience of the game are improved, and the requirement of the player on the game is met.
Example 4
The present embodiment provides an electronic device including one or more processors, a storage device for storing one or more programs, which when executed by the one or more processors, cause the electronic device to implement a non-stop game distribution method as in embodiment 2.
The present embodiment also provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor of a computer, causes the computer to execute a non-stop game distribution method of embodiment 2.
The foregoing is only a preferred embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art, who is within the scope of the present invention, should make equivalent substitutions or modifications according to the technical scheme of the present invention and the inventive concept thereof, and should be covered by the scope of the present invention.
The preferred embodiments of the invention disclosed above are intended only to assist in the explanation of the invention. The preferred embodiments are not intended to be exhaustive or to limit the invention to the precise form disclosed. Obviously, many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and the practical application, to thereby enable others skilled in the art to best understand and utilize the invention. The invention is limited only by the claims and the full scope and equivalents thereof.
Claims (7)
1. A non-stop game distribution system, comprising: the system comprises a version management module, a compatibility processing module and a client management module;
the version management module is used for version management and release of the game files;
the compatibility processing module is used for checking the compatibility degree between different versions of game files;
the client management module is used for updating and managing the client game version.
2. The method for issuing the game without stopping the machine is characterized by comprising a server processing flow and a client processing flow;
the steps of the server processing flow include:
step S1: pushing the game file to a game release server by a game operation and maintenance personnel, and marking the game version information;
step S2: the version management module attaches version information to all game files by calling an operating system API according to the game version information marked by the game operation staff;
step S3: version management module realizes version management of different version information game files through a difference checking method, realizes increment release, and saves server bandwidth and disk resources;
step S4: the compatibility processing module checks game files of different versions through a compatibility checking method, and marks different compatibility degrees of old versions according to new versions;
the steps of the client processing flow include:
step S5: the client management module runs on the client to update and check the game version;
step S6: the client management module acquires a configuration file patch from the server, executes the patch and updates the configuration file;
step S7: the client management module acquires a resource file from the server, places the resource file in a designated directory, and updates the resource file;
step S8: updating the executable file of the game without stopping by using the executable file without stopping updating method;
the game file comprises an executable file, a resource file and a configuration file;
the different degrees of compatibility of the new version with the old version include forward compatibility and incompatibility.
3. The non-stop game distribution method according to claim 2, wherein the step of step S3 of the difference checking method includes:
step S301: the method comprises the steps that file content is obtained, and a version management module obtains new version configuration file content and old version configuration file content by reading configuration compression files;
step S302: after the new version configuration file and the old version configuration file content are obtained, the file content is decomposed according to the format, so that comparison is facilitated;
step S303: after decomposing the content of the configuration file, the version management module uses a sequence searching algorithm to compare the configuration file of the new version with the configuration file of the old version line by line;
step S304: according to the result of the sequence searching algorithm, the version management module generates a series of patches describing the difference between the new version configuration file and the old version configuration file, wherein the patches comprise operations of inserting, deleting and modifying rows;
step S305: and realizing increment release through patches.
4. The non-stop game distribution method according to claim 2, wherein the step S4 compatibility checking method comprises the steps of:
step S401: the compatibility processing module reads game executable files of the new version and the old version;
step S402: comparing the executable files of the two different versions, and checking the function calling convention between the executable files; the transfer mode of the calling instruction and the related parameters in disassembly is included;
step S403: comparing the two executable files with different versions and checking whether the definition and layout of the data structure between the two executable files are consistent;
step S404: if the new version game executable and the old version game executable being compared are completely identical in the check of function calling conventions, data structure definitions and layouts, then the new version compatibility degree of this executable is marked as forward compatibility.
5. The non-stop game distribution method according to claim 2, wherein the step of the step S8 executable file non-stop update method comprises:
step S801: the client management module receives the new version executable file marked as incompatible by the compatibility processing module from the server;
step S802: annotating incompatible members within the executable file;
step S803: loading various members in the executable file into the memory;
step S804: injecting members with annotations into the memory;
step S805: after the members with annotations are injected in the memory, the old version executable is replaced with the new version executable.
6. An electronic device comprising one or more processors, storage means for storing one or more programs that, when executed by the one or more processors, cause the electronic device to implement a non-stop game distribution method as claimed in any one of claims 2 to 5.
7. A computer-readable storage medium, having stored thereon a computer program which, when executed by a processor of a computer, causes the computer to perform a non-stop game distribution method according to any one of claims 2 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311437469.7A CN117462961A (en) | 2023-10-31 | 2023-10-31 | Non-stop game release method, system, equipment and medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311437469.7A CN117462961A (en) | 2023-10-31 | 2023-10-31 | Non-stop game release method, system, equipment and medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117462961A true CN117462961A (en) | 2024-01-30 |
Family
ID=89626951
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311437469.7A Pending CN117462961A (en) | 2023-10-31 | 2023-10-31 | Non-stop game release method, system, equipment and medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117462961A (en) |
-
2023
- 2023-10-31 CN CN202311437469.7A patent/CN117462961A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108027722B (en) | Dynamically updating applications in compilation and deployment | |
| US10621068B2 (en) | Software code debugger for quick detection of error root causes | |
| US9830146B2 (en) | API lifecycle platform and version management | |
| US7681190B2 (en) | Minimum delta generator for program binaries | |
| US8082542B2 (en) | Load time in-lining of subroutines | |
| US8826225B2 (en) | Model transformation unit | |
| US20150294113A1 (en) | Method and system for performing a memory safety check of a program written in an unmanaged programming language | |
| US20130055291A1 (en) | Describing native application programming interfaces of an operating system with metadata | |
| US7500245B2 (en) | Changing code execution path using kernel mode redirection | |
| US10929149B2 (en) | Method and system for updating firmware | |
| US20200249925A1 (en) | On-demand loading of dynamic scripting language code for reduced memory usage | |
| US9317258B2 (en) | Dynamic validation of models using constraint targets | |
| US20070169018A1 (en) | Method and an apparatus for translating programming language code | |
| US9336128B2 (en) | Method and system for code analysis using symbolic types | |
| CN112667315A (en) | Game engine editor starting method and device, electronic equipment and storage medium | |
| WO2017087801A1 (en) | Dynamic update of an application in compilation and deployment | |
| CN110515647A (en) | A kind of static resource management method, device, equipment and storage medium | |
| US20130212565A1 (en) | Application analysis method, analysis system and recording medium | |
| CN111740948A (en) | Data packet issuing method, dynamic updating method, device, equipment and medium | |
| EP1376342A2 (en) | Single pass intermediate language verification algorithm | |
| Chajed et al. | Argosy: Verifying layered storage systems with recovery refinement | |
| CN113590327A (en) | Project resource detection method and device, electronic equipment and storage medium | |
| US11163545B2 (en) | Type inference optimization | |
| CN117462961A (en) | Non-stop game release method, system, equipment and medium | |
| CN112667310A (en) | Game engine editor starting method and device, electronic equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |