Weak networking data processing method and system based on long link
By encapsulating and asynchronously persisting user action objects on the client side and periodically verifying them on the server, the shortcomings of short-connection communication methods are solved, enabling real-time interaction and secure data processing in weak network environments, adapting to various network environments.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- TUYOO GAMES
- Filing Date
- 2026-03-16
- Publication Date
- 2026-05-15
AI Technical Summary
In existing technologies, short-link communication methods limit real-time interaction within games, increase communication overhead and the risk of data tampering, and cause fragmented game experiences in poor network environments. They also have a narrow scope of application and lack real-time verification mechanisms.
A weak network data processing method based on long-connections is adopted. The client encapsulates user operation behavior as Action behavior object instances, which are asynchronously persisted locally and periodically uploaded to the server for verification. The client processes local data based on the verification results to ensure state consistency.
In weak network environments, it enables real-time updates and data verification for user operations, ensuring user experience and data security, with good compatibility and adaptability to various network environments.
Smart Images
Figure CN122053612A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer communication technology, and in particular to a method and system for weak network data processing based on long links, a computing device, and a computer-readable storage medium. Background Technology
[0002] With the widespread adoption of mobile internet, weak network solutions have become increasingly important in certain gaming applications due to their ability to reduce user perception of network latency. Common weak network solutions typically employ short connections, where the client actively initiates requests to retrieve data, and the server responds passively. For example, in card games, a strategy of "offline calculation during gameplay and post-game verification" is used, disconnecting network interaction during gameplay and then reporting the results to the server for verification after each game ends.
[0003] However, the aforementioned existing technologies have significant drawbacks in practical applications. First, the use of short-connection communication prevents the server from proactively pushing messages to the client, limiting the implementation of real-time in-game interaction and increasing communication overhead due to frequent connection establishment. Second, the "in-game offline" strategy heavily relies on specific game types, resulting in a narrow scope of application, and the lack of a real-time verification mechanism within the game increases security risks such as data tampering. Furthermore, in out-of-game scenarios after the game ends, the network interaction mode often switches to a strong network mode. When in environments with poor network connectivity, users are highly susceptible to lag and latency, leading to a fragmented gaming experience and hindering the achievement of a smooth experience across all scenarios. Summary of the Invention
[0004] In view of this, embodiments of this application provide a method and apparatus for weak network data processing based on long links, a computing device and a computer-readable storage medium, to solve the technical defects existing in the prior art.
[0005] According to a first aspect of the embodiments of this application, a method for processing weak network data based on long-lived links is provided, including:
[0006] In response to user actions, the actions are encapsulated into Action objects and submitted to the client's business logic for simulation; the Action object is a transaction unit used to encapsulate user actions.
[0007] The client executes the Action behavior object instance based on the simulation results and asynchronously persists the Action behavior object instance locally.
[0008] Periodically send the locally persisted Action behavior object instances to the server for verification;
[0009] The client processes the local Action object instance based on the verification result returned by the server.
[0010] According to a second aspect of the embodiments of this application, a weak network data processing system based on long-lived connections is provided, including a client and a server:
[0011] The client includes:
[0012] An encapsulation unit is used to encapsulate a user's operation behavior into an Action behavior object instance in response to the user's operation behavior; the Action behavior object is a transaction unit used to encapsulate the user's operation behavior.
[0013] The simulation unit is used to simulate the business logic submitted to the client after instantiating the Action behavior object;
[0014] The persistence unit is used to asynchronously persist the Action behavior object instance locally while the client executes the Action behavior object instance;
[0015] The sending unit is used to periodically send locally persisted Action behavior object instances to the server for verification;
[0016] The processing unit is used to process the local Action behavior object instance based on the verification result returned by the server.
[0017] The servers include:
[0018] The verification unit is used to receive the Action behavior object instance sent by the client, and then use logic code that is isomorphic to the client to verify it and obtain the verification result.
[0019] The sending unit is used to send the verification result to the client.
[0020] According to a third aspect of the embodiments of this application, a client is provided, including:
[0021] An encapsulation unit is used to encapsulate a user's operation behavior into an Action behavior object instance in response to the user's operation behavior; the Action behavior object is a transaction unit used to encapsulate the user's operation behavior.
[0022] The simulation unit is used to simulate the business logic submitted to the client after instantiating the Action behavior object;
[0023] The persistence unit is used to asynchronously persist the Action behavior object instance locally while the client executes the Action behavior object instance;
[0024] The sending unit is used to periodically send locally persisted Action behavior object instances to the server for verification;
[0025] The processing unit is used to process the local Action behavior object instance based on the verification result returned by the server.
[0026] According to a fourth aspect of the embodiments of this application, a computing device is provided, including a memory, a processor, and computer instructions stored in the memory and executable on the processor, wherein the processor executes the instructions to implement the steps of the weak network data processing method based on long links.
[0027] According to a fifth aspect of the embodiments of this application, a computer-readable storage medium is provided that stores computer instructions, which, when executed by a processor, implement the steps of the weak network data processing method based on long links.
[0028] The weak network data processing method based on long connections provided in the embodiments of this application first optimistically executes transactional Action objects locally to update the presentation layer in real time, and asynchronously serializes and stores them to the local hard disk, effectively solving the data verification problem after abnormal process termination. Furthermore, the client asynchronously uploads the Action objects to the server for verification based on network conditions, the entire process being seamless for the user. Finally, the client executes a differentiated state synchronization strategy based on the verification results: if the verification passes, the client confirms the transaction commit and synchronously removes the corresponding records from memory and hard disk; if the verification fails, it corrects itself based on authoritative data returned by the server, forcibly aligning the local state. This scheme ensures that even in a weak network environment, the client state can ultimately maintain strict consistency with the server, balancing user experience and data security, and can also degrade to the standard long connection method when needed, exhibiting good compatibility. Attached Figure Description
[0029] Figure 1 This is a structural block diagram of the computing device provided in the embodiments of this application;
[0030] Figure 2 This is a schematic flowchart provided in an embodiment of this application;
[0031] Figure 3 This is a schematic diagram of a structure provided in an embodiment of this application. Detailed Implementation
[0032] Many specific details are set forth in the following description to provide a full understanding of this application. However, this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this application; therefore, this application is not limited to the specific embodiments disclosed below.
[0033] The terminology used in one or more embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this application. The singular forms “a,” “the,” and “the” used in one or more embodiments of this application and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” used in one or more embodiments of this application refers to and includes any or all possible combinations of one or more associated listed items.
[0034] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this application, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "in response to a determination".
[0035] This application provides a method and apparatus for processing weak network data based on long links, a computing device and a computer-readable storage medium, which will be described in detail in the following embodiments.
[0036] Figure 1 A structural block diagram of a computing device 100 according to an embodiment of this application is shown. The components of the computing device 100 include, but are not limited to, a memory 110 and a processor 120. The processor 120 is connected to the memory 110 via a bus 130, and a database 150 is used to store data.
[0037] The computing device 100 also includes an access device 140, which enables the computing device 100 to communicate via one or more networks 160. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 140 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Wi-MAX interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.
[0038] In one embodiment of this application, the aforementioned components of the computing device 100 and Figure 1 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 1The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.
[0039] The computing device 100 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 100 can also be a mobile or stationary server.
[0040] In one embodiment of this application, Figure 2 The flowchart illustrates a weak network data processing method based on long-lived connections provided in this application, including a client and a server, wherein a long-lived connection is established between the client and the server. The method includes:
[0041] Step 202: In response to the user's operation, the operation is encapsulated into an Action object instance and submitted to the client's business logic for simulation; the Action object is a transaction unit used to encapsulate the user's operation.
[0042] In this embodiment, when the client receives the user's operation behavior, it constructs a behavior object based on the operation behavior, and then submits the behavior object to the client's business logic for simulation in order to execute the user's operation behavior.
[0043] Specifically, when a user performs an operation on the client, an Action object instance is generated in response to the operation. In a weak network architecture, the Action object is a transaction unit used to encapsulate information such as user operation intent, business parameters, and metadata. Its corresponding business logic does not need to initiate network requests to the server.
[0044] Suppose a user clicks to use an item in the game, the client will respond to the action and generate an Action object instance, with the following data structure example:
[0045] {
[0046] "action_id": "Act_20231027_001",
[0047] "action_type": "USE_ITEM",
[0048] "timestamp": 1698400000,
[0049] "parameters": {
[0050] "item_id": "ITEM_HP_POTION_MID",
[0051] "item_count": 1,
[0052] "target_type": "SELF"
[0053] }
[0054] }
[0055] Furthermore, the client's business logic layer simulates the execution of the current Action object instance to obtain the corresponding action result tree; the action result tree includes at least one action result (ActionResult), and each action result (ActionResult) can include at least one action sub-result (Action SubResult). Each node in the action result tree represents an indivisible data change, such as a value update or state transition.
[0056] For example, after the client generates an Action behavior object instance, the client's business logic layer initiates a simulation run for that Action behavior object instance, including but not limited to:
[0057] The logic code calculates the execution results of business logic such as "how much mana is consumed," "how much damage is dealt," and "whether it's a critical hit." These results are then encapsulated into multiple Action Result nodes or Action SubResult nodes, combined into a behavior result tree. This binds all results corresponding to the Action behavior object instance within the behavior result tree, treating complex operations as a single transaction. A schematic behavior result tree structure is shown below:
[0058] [ClickActionTree]
[0059] ├── [Result_1: Deducted Blue Energy] -> Payload: {MP: -30}
[0060] └── [Result_2: Deals damage] -> Payload: {HP: -200, IsCrit: true}
[0061] └── [SubResult_1: Apply Burning] -> Payload: {Buff: Burning}
[0062] Preferably, the business logic layer generates a performance tree (PerformTree) based on the nodes of the behavior result tree while generating the behavior result tree. The performance tree exists only on the client side, and the nodes in the performance tree are bound to the nodes in the behavior result tree. It is responsible for scheduling UI animations, sound effects, vibrations, and other sensory feedback. An illustrative performance tree structure is shown below:
[0063] [PerformTree] — A client-side representation tree.
[0064] ├── PerformNode_1 (Performance tree node: e.g., "Play the coin reduction animation")
[0065] │ ├── BindResult: Result_1 (Binding logical node)
[0066] │ ├── Asset: "UI / CoinDown.prefab"
[0067] │ └── Trigger: ON_EXECUTE
[0068] │
[0069] ├── PerformNode_2 (Performance tree node: e.g., "Playing props to obtain special effects")
[0070] │ ├── BindResult: SubResult_1
[0071] │ └── Trigger: ON_SUCCESS
[0072] │
[0073] └── PerformNode_3 (Performance node: e.g., "screen vibration")
[0074] └── Trigger: ON_START
[0075] When the business logic simulation ends, the behavior result tree is completed. This behavior result tree contains all the atomic execution results corresponding to the Action behavior object, and it is a complete transaction during execution.
[0076] Step 204: The client executes the Action behavior object instance based on the simulation results and persists the Action behavior object instance locally.
[0077] In this embodiment, the client executes the Action object instance locally, allowing user actions to be executed immediately on the client without waiting for a server response. Specifically, when the client detects that the behavior result tree has been constructed, it traverses its nodes and transactionally commits the changed data to the local real data model to update the client state.
[0078] Preferably, when traversing the behavior result / sub-result node of the behavior result tree, if there is a bound performance tree node, the UI effect corresponding to the performance node is triggered to play.
[0079] Furthermore, while executing the Action object instance, the client persistently writes the Action object instance to the Action queue on the local storage medium, ensuring that each operation is saved to disk. Those skilled in the art will understand that the above process can be executed asynchronously on the client side, and will not be elaborated further here.
[0080] Preferably, while executing an Action object instance, the client persistently writes the Action object instance and its resulting set of state changes to the Action queue on the local storage medium. An Action object instance often causes multiple attribute changes, such as using a potion increasing HP, decreasing inventory space, or reducing durability. Therefore, in this embodiment, after the Action object instance is executed logically, it generates state increments affecting entity attributes. The client applies these state increments to the current state snapshot, and during the persistent storage phase, the client writes the Action object instance and its corresponding state increment to the local hard disk.
[0081] Preferably, when persistently writing the Action behavior object instance and the set of state changes it causes to the local storage medium, the method further includes writing the Action behavior object instance and a snapshot of the user's global attributes after executing the instance to the Action queue of the local storage medium.
[0082] Step 206: Periodically send the locally persisted Action behavior object instances to the server for verification.
[0083] In this step, the client further adds the locally persisted Action object instance to the network verification queue in memory, and periodically retrieves the Action object instance that needs to be verified from the network verification queue in the background of the client, and sends it asynchronously to the server for verification through a long-connection network.
[0084] In one feasible implementation, the client monitors network latency and packet loss rate parameters in real time. When the network latency is lower than a preset threshold, it scans and sends Action behavior object instances in the network verification queue at a shorter first time interval (e.g., 200ms). When the network latency is higher than the preset threshold (in a weak network environment), it automatically adjusts the scanning interval to a longer second time interval (e.g., 2000ms) to reduce invalid retransmissions and lower device power consumption.
[0085] In another feasible implementation, the length of the network queue to be verified is monitored simultaneously. When the number of Action object instances to be verified reaches a preset threshold (e.g., 10), the sending is triggered immediately without waiting for the timer period to end.
[0086] Those skilled in the art should understand that the above-described periodic sending scheme is merely an example and not an exhaustive list, and those skilled in the art can determine the timing of periodic sending based on the actual situation.
[0087] Furthermore, after receiving the Action object instance sent by the client, the server uses logic code that is isomorphic to the client to execute the same logic on the operation therein, thereby simulating the generation of a behavior result tree. Then, the server's execution result is obtained based on the behavior result tree, and the client performs verification based on the server's execution result.
[0088] In another feasible implementation, the client further adds the locally persistent Action object instance and its associated data to a network verification queue in memory. After receiving the Action object instance and its associated data from the client, the server deserializes it and uses isomorphic logic code to verify the operations and values to obtain the verification result. In this embodiment, the isomorphic front-end and back-end architecture establishes a logical benchmark across network boundaries, ensuring the feasibility and accuracy of the asynchronous verification mechanism, enabling the server to accurately compare the client's prediction results with the server's calculation results.
[0089] Specifically, the server's isomorphic business logic layer simulates and generates a behavior result tree based on the Action behavior object instance sent by the client. Then, based on the behavior result tree, the server obtains the execution result and compares it with the state change set sent by the client to obtain the verification result.
[0090] Step 208: The client processes the local persistent data based on the verification result returned by the server.
[0091] In this embodiment of the application, the client receives the verification result data packet returned by the server and performs corresponding processing on the local Action behavior object instance of the client according to the verification result.
[0092] In one feasible implementation, the verification result data packet contains a unique identifier for the target Action object and the execution result obtained by the server based on that target Action object. The client compares the execution results to obtain the final verification status.
[0093] In another feasible implementation, the verification result data packet contains at least a unique identifier of the target Action object and a verification status generated by the server, wherein the verification status is used to characterize the server's verification result of the Action object.
[0094] The above verification status includes "verification passed" and "verification failed".
[0095] Specifically, if the verification status is "verification passed", it indicates that the operation-behavior pair calculated by the server is consistent with the operation-behavior pair calculated by the client. At this time, the client performs transaction commit and resource release operations, including:
[0096] Remove queue record: Removes the data related to the target Action behavior object instance from the network queue to be verified in memory, freeing up memory.
[0097] Clean up persistent data: Send a delete command to the local storage system to clear the serialized data files associated with the Action object stored on the local storage medium.
[0098] If the verification status code is "verification failed", it indicates that the client's calculation result does not match the server's authoritative calculation result. At this time, it is determined that the client's logic is abnormal or that there is cheating behavior. The client performs an environment reset and strong data synchronization operation: clear all local data model caches on the client, including all unverified and verified Action persistence-related data; further, redirect the client state to the initialization stage (such as returning to the login page), and send a full data pull request to the server to obtain the latest global state snapshot stored on the server side, overwriting the client's local data.
[0099] In one embodiment of this application, for critical business scenarios involving data security, when a strong network API behavior call such as recharge or transaction is detected, the execution mode is automatically switched from weak network mode to a standard long connection (Client-Server / Server-Client) structure, thereby ensuring good compatibility with other network connection methods.
[0100] Specifically, in this process, the client first suspends the current critical business request and performs forced synchronous verification on all Action objects in the local storage and memory verification queue until the queue is cleared and the local state is aligned with the server's authoritative state. Only then does the client continue to initiate the critical business request and process it using a synchronous interaction method of "request-wait-response". This eliminates the data uncertainty risk caused by optimistic predictions in a weak network architecture at critical nodes and ensures the atomicity and absolute security of the core business logic.
[0101] This application also provides a method for handling abnormal recovery scenarios, used to address various situations where client processes terminate abnormally. Abnormal termination of a client process refers to the phenomenon where, during the execution of a client application, the lifecycle of its main process is forcibly interrupted without executing a normal exit procedure due to unexpected internal errors or external intervention. Specifically, this phenomenon includes, but is not limited to, the following illustrative scenarios:
[0102] The client program code encounters an uncaught exception during execution, causing the runtime environment to throw an error and forcibly terminate the process. This situation usually corresponds to what is commonly known as a "crash".
[0103] When the operating system of the client is experiencing resource constraints (such as memory and CPU quotas), it may forcibly terminate low-priority client processes running in the background or foreground according to the process priority policy, in order to free up resources for the system to use.
[0104] Users can forcibly terminate the client process through the operating system's task manager, debugging tools, or specific gestures, causing the process to be destroyed immediately before the data persistence and cleanup logic is completed.
[0105] The client device may be restarted or shut down due to force majeure factors such as power depletion, hardware failure or operating system crash, which may cause the running client process to be interrupted unexpectedly.
[0106] Therefore, in this embodiment of the application, when the client process terminates abnormally and the user re-enters the login process, the client checks whether there is an unverified Action behavior object instance in the local storage medium.
[0107] If it exists, read the unverified Action object instance from the local storage medium and send it to the server for verification via the asynchronous verification system;
[0108] If the verification is successful, the client restores the game state corresponding to the latest verified Action behavior object instance; if the verification fails, the local data is overwritten based on the final state data sent by the server.
[0109] If it does not exist, the local data will be overwritten based on the final status data issued by the server.
[0110] This application also provides a data processing method for weak network environments, used to handle users playing games in scenarios with unstable mobile signals (such as subways and elevators). In the above scenario, the client executes a series of actions and writes them to the local hard drive, but due to network interruption, these actions cannot be sent to the server for verification. At this time, the user does not exit the game; the network is only temporarily disconnected. Subsequently, after the network is restored, the data verification is performed again.
[0111] In this method, when the client detects a network interruption, it continues to execute the newly generated Action object instance and persists it to the Action queue in the local storage medium and to the network verification queue in memory.
[0112] When the client detects that the network has been restored, the client reads the data related to the Action object instances that have been backlogged in the network verification queue and sends them to the server for verification.
[0113] In the above embodiments of this application, in order to solve the technical problems existing in the current weak network architecture, this solution constructs a closed-loop processing mechanism with Action behavior objects as the core. The behavior result tree simulated by the Action behavior object is designed as an operation unit with transactional and atomic characteristics. It decomposes a complex operation into a tree composed of atomic elements through the composition pattern, and performs precise process control on its construction, simulation, execution and performance at the business logic level, thereby encapsulating complete business logic and state change information, ensuring the logical indivisibility of a single operation, and the client's state is only confirmed to have changed after receiving a valid and complete result from the server.
[0114] In terms of execution flow, the client first optimistically executes the Action object locally to update the presentation layer in real time, and asynchronously serializes and stores it to the local hard drive, effectively solving the data verification problem after abnormal process termination. Furthermore, the client asynchronously uploads the Action object to the server for verification based on network conditions, a process seamless for the user. Finally, the client executes a differentiated state synchronization strategy based on the verification results: if verification passes, the client confirms the transaction commit and synchronously removes the corresponding record from memory and hard drive; if verification fails, it corrects itself based on authoritative data returned by the server, forcibly aligning the local state. This solution ensures that even in weak network environments, the client state ultimately maintains strict consistency with the server, balancing user experience and data security. It can also degrade to a standard long-lived connection method when needed, offering good compatibility.
[0115] Corresponding to the above method embodiments, this application also provides an embodiment of a weak network data processing system based on long links, such as... Figure 3 As shown, the system includes a client and a server:
[0116] The client includes:
[0117] An encapsulation unit is used to encapsulate a user's operation behavior into an Action behavior object instance in response to the user's operation behavior; the Action behavior object is a transaction unit used to encapsulate the user's operation behavior.
[0118] The simulation unit is used to simulate the business logic submitted to the client after instantiating the Action behavior object;
[0119] The persistence unit is used to asynchronously persist the Action behavior object instance locally while the client executes the Action behavior object instance;
[0120] The sending unit is used to periodically send locally persisted Action behavior object instances to the server for verification;
[0121] The processing unit is used to process the local Action behavior object instance based on the verification result returned by the server.
[0122] The servers include:
[0123] The verification unit is used to receive the Action behavior object instance sent by the client, and then use logic that is isomorphic to the client to verify it and obtain the verification result.
[0124] The sending unit is used to send the verification result to the client.
[0125] The above is an illustrative scheme of a weak network data processing system based on long links according to this embodiment. It should be noted that the technical solution of this weak network data processing system based on long links belongs to the same concept as the technical solution of the aforementioned weak network data processing method based on long links. Details not described in detail in the technical solution of this weak network data processing system based on long links can be found in the description of the technical solution of the aforementioned weak network data processing method based on long links.
[0126] One embodiment of this application also provides a computing device, including a memory, a processor, and computer instructions stored in the memory and executable on the processor, wherein the processor executes the instructions to implement the steps of the weak network data processing method based on long links.
[0127] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the above-described weak network data processing method based on long links belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-described weak network data processing method based on long links.
[0128] An embodiment of this application also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the weak network data processing method based on long links as described above.
[0129] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solution of the aforementioned weak network data processing method based on long links. Details not described in detail in the technical solution of the storage medium can be found in the description of the technical solution of the aforementioned weak network data processing method based on long links.
[0130] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
[0131] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.
[0132] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.
[0133] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.
[0134] The preferred embodiments disclosed above are merely illustrative of this application. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this application. These embodiments are selected and specifically described in this application to better explain the principles and practical applications of this application, thereby enabling those skilled in the art to better understand and utilize this application. This application is limited only by the claims and their full scope and equivalents.
Claims
1. A method for processing weak network data based on long-lived links, characterized in that, include: In response to user actions, the actions are encapsulated into Action objects and submitted to the client's business logic for simulation. Action objects are transaction units used to encapsulate user actions. The client executes the Action behavior object instance based on the simulation results and asynchronously persists the Action behavior object instance locally. Periodically send the locally persisted Action behavior object instances to the server for verification; The client processes the local Action object instance based on the verification result returned by the server.
2. The method according to claim 1, wherein, The business logic that responds to user actions, encapsulates the actions into Action object instances, and submits them to the client includes: An Action object instance is generated for the operation behavior. The client's business logic layer simulates the operation based on the Action object instance to construct a behavior result tree. The behavior result tree includes at least one behavior result and at least one behavior sub-result, and each node of the behavior result tree represents an indivisible data change.
3. The method according to claim 2, wherein, The client's business logic layer also includes simulating the operation based on the Action behavior object instance: A presentation tree is generated, which maps changes in logical data to visual rendering effects of the presentation layer; wherein, the nodes in the presentation tree are bound to the nodes in the behavior result tree.
4. The method according to claim 1, wherein, The client executes the Action behavior object instance based on the simulation result, and asynchronously persists the Action behavior object instance locally, including: When the client executes the Action object instance, it traverses the nodes of its behavior result tree and commits the changed data to the local real data model in a transactional manner to update the client state; at the same time, it asynchronously persists the Action object instance to the Action queue in the client's local storage medium.
5. The method according to claim 4, wherein, Asynchronously persisting the Action object instance to the Action queue in the client's local storage medium includes: The Action object instance and the set of state changes it causes are persistently written to the Action queue in the local storage medium; the set of state changes includes the state increment corresponding to the Action object instance, or the user global attribute snapshot corresponding to the Action object instance.
6. The method according to claim 5, wherein, The step of periodically sending locally persisted Action behavior object instances to the server for verification includes: The locally persisted Action object instance or Action object instance and its resulting set of state changes are added to the network verification queue in memory, and the relevant data of the Action object instance to be verified is periodically retrieved from the network verification queue in the background and sent to the server for verification.
7. The method according to claim 1, wherein, The client processes the local Action object instance based on the validation result returned by the server, including: When the verification result includes a verification status, if the verification status is "verification passed", the client removes the target Action behavior object instance from the network queue to be verified and clears the serialized data file related to the target Action behavior object instance stored in the local storage medium. If the verification status is verification failure, clear all local data model caches on the client; further, after redirecting the client status to the initialization phase, obtain the latest global status snapshot stored on the server to overwrite the local data on the client.
8. The method according to claim 1, wherein, The method also includes: When the client detects a business request that requires a strong network connection, it suspends the current call and performs forced verification on all Action behavior object instances in the local storage and the verification queue in memory before continuing to initiate the business request.
9. The method according to claim 1, wherein, The method also includes: When the client process terminates abnormally and re-enters the login process, it checks whether there is an unverified Action behavior object instance in the client's local storage medium. If it exists, read the unverified Action object instance from the local storage medium and send it to the server for verification; If the verification is successful, the client will restore the game state corresponding to the verified Action behavior object instance; if the verification fails, the local data will be overwritten based on the final state data sent by the server. If it does not exist, the final state data is obtained from the server and overwritten with the local data.
10. The method according to claim 5, wherein, The method also includes: When the client detects a network interruption, it continues to execute the newly generated Action object instance; and persists the generated Action object instance to the Action queue in the local storage medium and the network verification queue. When the client detects that the network has been restored, it reads the Action object instances that have been accumulated in the network verification queue and sends them to the server for verification.
11. A weak network data processing system based on long-lived connections, comprising a client and a server, characterized in that the client... include: An encapsulation unit is used to encapsulate a user's operation behavior into an Action behavior object instance in response to the user's operation behavior; the Action behavior object is a transaction unit used to encapsulate the user's operation behavior. The simulation unit is used to simulate the business logic submitted to the client after instantiating the Action behavior object; An asynchronous persistence unit is used to asynchronously persist the Action behavior object instance locally while the client executes the Action behavior object instance; The sending unit is used to periodically send locally persisted Action behavior object instances to the server for verification; The processing unit is used to process the local Action behavior object instance based on the verification result returned by the server. The servers include: The verification unit is used to receive the Action behavior object instance sent by the client, and then execute it using logic that is isomorphic to the client to obtain the verification result. The sending unit is used to send the verification result to the client.
12. A client comprising: An encapsulation unit is used to encapsulate the user's operation behavior into an Action behavior object instance in response to the user's operation behavior; The Action object is a transaction unit used to encapsulate user operation behavior; The simulation unit is used to simulate the business logic submitted to the client after instantiating the Action behavior object; An asynchronous persistence unit is used to asynchronously persist the Action behavior object instance locally while the client executes the Action behavior object instance; The sending unit is used to periodically send locally persisted Action behavior object instances to the server for verification; The processing unit is used to process the local Action behavior object instance based on the verification result returned by the server.
13. A computing device, comprising a memory, a processor, and computer instructions stored in the memory and executable on the processor, characterized in that, When the processor executes the instructions, it implements the steps of the method according to any one of claims 1-10.
14. A computer-readable storage medium storing computer instructions, characterized in that, When executed by the processor, this instruction implements the steps of the method according to any one of claims 1-10.