Resource allocation method, device, storage medium and computer program product

Abstract

Embodiments of the present application disclose a resource allocation method, device, storage medium and computer program product. The method comprises: a first function node receiving a first request sent by a second function node; the first request representing a resource pre-occupancy request; in response to the first request, generating a challenge task; sending the challenge task to a third function node, so that the third function node generates first information based on the challenge task, and synchronizes the first information to a blockchain network; the first information representing zero-knowledge proof information; when the first information is verified by a blockchain node in the blockchain network, allocating a pre-occupancy resource instance for the first request.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a resource allocation method, device, storage medium, and computer program product. Background Technology

[0002] Currently, in related technologies, during peak gaming periods, due to self-interest or concerns about other game developers occupying the resources and leaving them without access, game developers often purchase or rent additional resource instances (i.e., resource pre-allocation) to prepare for resource instance shortages during peak gaming periods. However, in practice, the actual utilization rate of these pre-allocated resources is usually not very high, indicating false pre-allocation and resulting in a high vacancy rate for pre-allocated resources. Summary of the Invention

[0003] To address the technical problems existing in related technologies, embodiments of this application provide a resource allocation method, device, storage medium, and computer program product.

[0004] To achieve the above objectives, the technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide a resource allocation method, the method comprising: Receive a first request sent by the second functional node; the first request represents a resource pre-allocation request. In response to the first request, a challenge task is generated; The challenge task is sent to a third functional node, which generates first information based on the challenge task and synchronizes the first information to the blockchain network; the first information represents zero-knowledge proof information. When a blockchain node in the blockchain network verifies the first information, it allocates a pre-reserved resource instance to the first request.

[0005] Secondly, embodiments of this application also provide a resource allocation device, including: a processor and a memory for storing computer programs capable of running on the processor; When the processor runs the computer program, it executes the steps of the resource allocation method described in the embodiments of this application.

[0006] Thirdly, embodiments of this application also provide a storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the resource allocation method described in embodiments of this application.

[0007] Fourthly, embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the resource allocation method described in embodiments of this application.

[0008] The resource allocation method, device, storage medium, and computer program product provided in this application embodiment include: a first functional node receiving a first request sent by a second functional node; the first request representing a resource pre-allocation request; in response to the first request, generating a challenge task; sending the challenge task to a third functional node, so that the third functional node generates first information based on the challenge task and synchronizes the first information to the blockchain network; the first information representing zero-knowledge proof information; and when the blockchain node in the blockchain network verifies the first information, allocating a pre-allocated resource instance to the first request. Using the technical solution of this application embodiment, the first functional node generates a challenge task in response to a resource pre-allocation request. After sending the challenge task to the third functional node, the third functional node executes the generated challenge task and generates zero-knowledge proof (ZKP) information. When the zero-knowledge proof information is verified by the blockchain node, a pre-allocated resource instance is allocated to the resource pre-allocation request. In this way, the second functional node that initiated the resource pre-allocation request is provided with a proof of pre-allocation efficiency (PoPE) through blockchain and zero-knowledge proof technology. Only after the blockchain node verifies the information can the pre-allocated resources be allocated, thus preventing false pre-allocation behavior, reducing the vacancy rate of pre-allocated resources, and improving the utilization rate of pre-allocated resources. Attached Figure Description

[0009] Figure 1 A flowchart illustrating the resource allocation method in an embodiment of this application. Figure 1 ; Figure 2 This is a schematic diagram illustrating the process of embedding timestamp information into the metadata of a challenge task according to an embodiment of this application. Figure 3 This is a schematic diagram illustrating the process of the cloud gaming client resource scheduling center applying to join the shared resource service in an embodiment of this application; Figure 4 A schematic diagram illustrating the process of the cloud gaming client resource scheduling center applying for an update of a shared resource instance in an embodiment of this application; Figure 5 This is a schematic diagram illustrating the process of the cloud gaming client resource scheduling center requesting to exit the shared resource service, as described in this application embodiment. Figure 6 A flowchart illustrating the resource allocation method in an embodiment of this application. Figure 2 ; Figure 7This is a schematic diagram illustrating the process of generating challenge tasks according to an embodiment of this application; Figure 8 This is a schematic diagram of a device for sharing cloud gaming resource instances according to an embodiment of this application; Figure 9 This is a schematic diagram illustrating the process of a cloud gaming client resource scheduling center requesting the use of shared resources, as described in an embodiment of this application. Figure 10 This is a schematic diagram illustrating the interaction of scheduling shared resources according to an embodiment of this application; Figure 11 This is a schematic diagram illustrating the interaction of a user running a game using shared resources, as described in an embodiment of this application. Figure 12 This is a schematic diagram of the composition structure of the resource allocation device according to an embodiment of this application; Figure 13 This is a schematic diagram of the hardware structure of the resource allocation device according to an embodiment of this application. Detailed Implementation

[0010] The present application will now be described in further detail with reference to the accompanying drawings and embodiments.

[0011] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0012] This application provides a resource allocation method, which is applied to a first functional node. Figure 1 A flowchart illustrating the resource allocation method in an embodiment of this application. Figure 1 ,like Figure 1 As shown, the resource allocation method includes: Step 101: Receive the first request sent by the second functional node; the first request represents a resource pre-allocation request.

[0013] Step 102: In response to the first request, generate a challenge task.

[0014] Step 103: Send the challenge task to the third functional node, so that the third functional node generates first information based on the challenge task and synchronizes the first information to the blockchain network; the first information represents zero-knowledge proof information.

[0015] Step 104: When the blockchain node in the blockchain network verifies the first information, it allocates a pre-reserved resource instance to the first request.

[0016] Here, the resource allocation method of this application embodiment can be applied to games such as cloud gaming scenarios.

[0017] Here, the first functional node can be a shared resource scheduling center, which can also be called a shared scheduling center or a shared resource center. This application embodiment does not limit the name of the shared resource scheduling center, as long as it can achieve its function.

[0018] Here, the second functional node can be a cloud gaming client resource scheduling center. This cloud gaming client resource scheduling center can also be called a cloud gaming vendor scheduling center, or simply a cloud gaming scheduling center. This application embodiment does not limit the name of the cloud gaming client resource scheduling center, as long as it fulfills its function. It should be noted that the cloud gaming client resource scheduling center is a functional component responsible for scheduling cloud gaming instances for a specific cloud gaming application.

[0019] Here, the third functional node can be a cloud gaming provider node, which can also be called a cloud gaming operator node, or simply a cloud gaming provider. This application embodiment does not limit the name of the cloud gaming provider node, as long as it can achieve its function.

[0020] In practical applications, after receiving the resource pre-allocation request (referred to as the pre-allocation request) sent by the cloud gaming client resource scheduling center, the shared resource scheduling center generates a challenge task generator. The performance test task is then started through the challenge task generator, generating challenge tasks from the rendering dimension, network dimension, and resource computing dimension respectively.

[0021] Based on this, in one embodiment, generating the challenge task in response to the first request includes: In response to the first request, basic parameters are generated based on the first request; Based on the aforementioned basic parameters, dynamic parameters are generated; The challenge task is generated based on the basic parameters and the dynamic parameters.

[0022] Here, based on the resource allocation requested in the first request (i.e., the resource pre-allocation request), the challenge task includes the following tasks: rendering verification task, network verification task, and resource calculation verification task. It can be seen that the challenge task in this embodiment is a three-dimensional challenge task. Specifically, the challenge task includes verification tasks in the rendering dimension, network dimension, and resource calculation dimension, and each verification task can map to the actual resource capabilities.

[0023] Here, in one embodiment, generating basic parameters based on the first request includes: The first request is parsed to obtain the requested resource type; The basic parameters are generated based on the requested resource type.

[0024] Here, the first request includes the following pre-allocation request parameters: cloud gaming vendor identifier (vendor_id); requested resource type (resource_type); hardware resource type (hard_type); Quality of Service (QoS) requirements; and pre-allocation market duration.

[0025] In one embodiment, after receiving a resource pre-allocation request from the cloud gaming client's resource scheduling center, the shared resource scheduling center can parse the request to obtain the requested resource type. Then, it verifies the validity of the requested resource type. If the validity verification passes, it extracts basic parameters based on the requested resource type. These basic parameters can be represented as "base". The types of basic parameters can include, for example, rendering complexity, network test intensity, and computational task scale.

[0026] In practical applications, the extracted basic parameters are used as input data, and dynamic parameters for the challenge task are generated based on a preset dynamic adjustment strategy table.

[0027] Therefore, in one embodiment, generating dynamic parameters based on the basic parameters includes: Retrieve the preset dynamic adjustment strategy table; The dynamic parameters are generated based on the basic parameters and the dynamic adjustment strategy table.

[0028] Here, the dynamic parameters of the challenge task can also be called the dynamic parameters of the test task. The dynamic adjustment strategy table can be preset according to actual needs.

[0029] In one embodiment, generating the dynamic parameters based on the basic parameters and the dynamic adjustment strategy table includes: determining whether a triggering condition is met; and generating the dynamic parameters based on the basic parameters and the dynamic adjustment strategy table when the triggering condition is met.

[0030] In one embodiment, the dynamic adjustment strategy table includes a dynamic adjustment algorithm. The step of generating the dynamic parameters based on the basic parameters and the dynamic adjustment strategy table when the triggering condition is determined to be met includes: inputting the basic parameters into the dynamic adjustment algorithm to obtain the dynamic parameters when the triggering condition is determined to be met.

[0031] It should be noted that the triggering conditions may include, for example, a graphics processing unit (GPU) of the type being a high-end graphics card, a current regional network congestion index being greater than a network congestion index threshold (e.g., a network congestion index threshold of 0.7), or a cloud gaming provider's historical credit score being greater than a credit score threshold (e.g., a credit score threshold of 90).

[0032] For example, the dynamic adjustment strategy table can be shown in Table 1 below:

[0033] Table 1 Here, card_tier represents the graphics card level, and congestion represents the network congestion index.

[0034] In practical applications, in order to improve the unpredictability of test tasks (i.e. challenge tasks), the shared resource scheduling center also needs to generate chaotic parameters and inject the chaotic parameters into the challenge tasks.

[0035] Based on this, in one embodiment, generating the challenge task based on the basic parameters and the dynamic parameters includes: Obtain the chaotic sequence; The chaotic sequence is applied to the dynamic parameters to generate chaotic parameters; The challenge task is generated based on the basic parameters and the chaos parameters.

[0036] Here, the chaos parameter can also be called the fluctuation parameter, which refers to the parameter that fluctuates within a set range.

[0037] In one embodiment, obtaining the chaotic sequence includes: obtaining the hash value of the latest block; and deriving the chaotic sequence based on the hash value of the latest block.

[0038] Here, the shared resource scheduling center obtains the hash value of the latest block through the blockchain, uses the hash value as a chaotic sequence, and then applies the chaotic sequence to the dynamic parameters to obtain chaotic parameters. That is, the dynamic parameters are made to fluctuate chaotically within a specific range to generate chaotic parameters.

[0039] Here, after generating the basic parameters and chaotic parameters through the above steps, the generation of the challenge task based on the basic parameters and chaotic parameters can be achieved by assembling the task based on the basic parameters and chaotic parameters; that is, after generating the basic parameters and chaotic parameters, the shared resource scheduling center uses the generated basic parameters and chaotic parameters as the basic test dimensions to generate the challenge task; wherein, the challenge task can be the original challenge task use case.

[0040] In this embodiment of the application, the challenge task includes one or more of the following information: Task identification information; First watermark information; the first watermark information represents visual watermark information obtained based on the binary sequence of the challenge task; Second watermark information; the second watermark information represents the metadata watermark information of the challenge task, and the metadata watermark information includes the timestamp information in the metadata of the challenge task.

[0041] Here, the task identification information can be represented as Task_Id. For each task, a task identification information (Task_Id) is generated using a specific data object in a Merkle tree format, serving as the task's DNA. The Merkle tree is a cryptographic hash tree structure used for data integrity verification, typically a binary tree structure. It uses a hash algorithm to hierarchically organize data. The root node of the Merkle tree uniquely identifies the entire dataset. If any part of the data is tampered with, the root hash value will change, thus achieving efficient verification.

[0042] Here, when rendering the challenge task, the binary sequence of the challenge task is first obtained, and then the binary sequence of the challenge task is injected as visual watermark information (i.e., the first watermark information) and rendered.

[0043] Here, the timestamp information in the metadata of the challenge task includes first timestamp information and second timestamp information. The first timestamp information represents the signature timestamp information corresponding to the start of the frame, and the second timestamp information represents the signature timestamp information corresponding to the end of the frame.

[0044] Here, the first functional node (i.e., the shared resource scheduling center) sends the generated challenge task to the third functional node (i.e., the cloud gaming provider node). The cloud gaming provider node receives the challenge task, generates first information based on the challenge task, specifically, the cloud gaming provider node executes the challenge task, obtains the result of the task execution, and generates the first information (i.e., zero-knowledge proof information) based on the result of the task execution.

[0045] Here, the first information includes one or more of the following: encrypted watermark information; key transmission information; complete hash chain.

[0046] In practical applications, to ensure the authenticity of task execution, an authenticity verification is added to the execution of each verification task. Specifically, when the cloud gaming provider node executes the rendering verification task, it embeds encrypted watermark information in the frequency domain and uses a challenge key to encrypt the watermark; when the cloud gaming provider node executes the network verification task, it uses the key specified in the challenge task (i.e., key transmission information) to test data transmission in a real network; when the cloud gaming provider node executes the resource computation verification task, it calculates the entire hash chain (i.e., the complete hash chain) through the state hash chain, without skipping any computation steps, and outputs the computation result.

[0047] In one embodiment, after generating the first piece of information, namely zero-knowledge proof information, the cloud gaming provider node can synchronize this information to the blockchain nodes in the blockchain network. Upon receiving the zero-knowledge proof information, the blockchain nodes verify it to obtain a verification result. The shared resource scheduling center sends a query request to the blockchain nodes in the blockchain network to inquire about the verification result of the zero-knowledge proof information. If the verification result indicates that the zero-knowledge proof information has passed verification, the shared resource scheduling center allocates a pre-allocated resource instance to the resource pre-allocation request; that is, the shared resource scheduling center schedules resources from the shared resource pool to allocate to the resource pre-allocation request. If the verification result indicates that the zero-knowledge proof information has failed verification, the shared resource scheduling center does not allocate a pre-allocated resource instance to the resource pre-allocation request.

[0048] In practical applications, before generating the first information based on the challenge task, the third functional node also needs to verify the challenge task. That is, it needs to comprehensively verify the visual watermark information and metadata watermark information embedded in the challenge task to obtain the authenticity of its task execution and determine whether the challenge task has been verified.

[0049] Based on this, in one embodiment, the third functional node generates first information based on the challenge task, including: verifying the challenge task to obtain a verification result; and generating the first information based on the challenge task when the verification result indicates that the challenge task has been verified.

[0050] Here, in one embodiment, verifying the challenge task to obtain a verification result includes: extracting visual watermark information and metadata watermark information from the challenge task; and performing comprehensive verification on the visual watermark information and the metadata watermark information to obtain a verification result.

[0051] Specifically, firstly, visual watermark information is extracted from the challenge task. Based on the extracted visual watermark information, the task identifier (i.e., Task_Id) is reconstructed. The Task_Id is generated using the Merkle tree method. The extracted visual watermark information is then verified to ensure consistency with the target visual watermark information. Next, metadata watermark information is parsed from the challenge task. The timestamp information in the metadata of the challenge task is obtained from the metadata watermark information. The correctness of the timestamp information in the metadata of the challenge task and the continuity of time are then verified.

[0052] Here, the continuity of time is verified through metadata watermark information. When the third functional node (i.e., the cloud gaming provider node) executes the challenge task, it needs to interact with the time server to obtain the signature timestamp information corresponding to the start of the frame (i.e., the first timestamp information) and the signature timestamp information corresponding to the end of the frame (i.e., the second timestamp information), and embed the signature timestamp information corresponding to the start of the frame and the signature timestamp information corresponding to the end of the frame into the metadata of the challenge task.

[0053] Figure 2 This is a schematic diagram illustrating the process of embedding timestamp information into the metadata of a challenge task, as described in an embodiment of this application. Figure 2 As shown, firstly, the cloud gaming provider node requests the signature timestamp information corresponding to the start of the frame from the time server. After receiving the request, the time server returns the signature timestamp information corresponding to the start of the frame to the cloud gaming provider node, which can be represented as TS1. The cloud gaming provider node then renders the frame (containing TS1). Next, the cloud gaming provider node requests the signature timestamp information corresponding to the end of the frame from the time server. After receiving the request, the time server returns the signature timestamp information corresponding to the end of the frame to the cloud gaming provider node, which can be represented as TS2. Finally, after receiving TS1 and TS2, the cloud gaming provider node embeds (TS1, TS2) into the metadata of the challenge task.

[0054] In one embodiment, the method further includes: When the occupancy rate of the game instance reaches a preset first threshold, a second request is received from the second functional node; The second request represents a shared resource preparation request, and the second request is a prerequisite request for the first request.

[0055] Here, the game running instance can also be called a cloud gaming running instance, or a game instance, or a game running instance. This application embodiment does not limit the name of the game running instance.

[0056] Here, the occupancy rate of the game running instances can be the ratio of the number of cloud game running instances to the total number of cloud game operators (i.e., cloud game provider nodes) purchased or leased. The first threshold is the threshold for pre-occupying shared resources set by the cloud game operator based on actual needs. That is, when the ratio of the number of cloud game running instances to the total number of cloud game operators purchased or leased reaches the first threshold, the second functional node (i.e., the cloud game terminal resource scheduling center) initiates a shared resource preparation request to the first functional node (i.e., the shared resource scheduling center), and after PoPE verification, the idle resource instances are locked into a pre-occupied state.

[0057] In one embodiment, the shared resource scheduling center obtains the latest status of shared resource instances with installed cloud game packages and filters out resource instances that are not idle. At this point, C resource instances are selected. If there are fewer than C available resource instances, the actual number of available resource instances is used. The shared resource scheduling center initiates a resource pre-allocation request to the cloud game client resource scheduling center corresponding to the actual available resource instances. The cloud game client resource scheduling center parses the received resource pre-allocation request and marks the resource instances in the request as pre-allocated. The C value is calculated by multiplying the contribution value of the shared resource instances in the game by a first threshold coefficient configured by the shared resource scheduling center.

[0058] In practical applications, when the occupancy rate of a game instance reaches the second threshold, the resource instance's status is upgraded to an uncancellable occupied state.

[0059] Based on this, in one embodiment, the method further includes: When the utilization rate of the game instance reaches a preset second threshold, a third request is received from the second functional node; the third request represents a resource occupancy request.

[0060] Here, the second threshold is the threshold for the actual occupation of shared resources set by the cloud gaming operator based on actual needs. When the ratio of the number of running cloud gaming instances to the total number of cloud gaming instances purchased or leased by the cloud gaming operator reaches the second threshold, it indicates that the number of runnable cloud gaming instances is almost exhausted. At this time, the cloud gaming client resource scheduling center initiates a resource occupation request to the shared resource scheduling center, and the shared resource scheduling center initiates a device occupation request to the cloud gaming client resource scheduling center where the pre-occupied device is located. The occupation status cannot be passively canceled; only the shared resource scheduling center can initiate a cancellation request.

[0061] Here, resource instances in a pre-reserved state can be cancelled in two ways: first, if they are not actually reserved or run within the set time, the pre-reservation state can be cancelled; second, if the current game's scheduling center (i.e., the cloud gaming client resource scheduling center) has no other available resource instances, the pre-reservation state of the operator's resource instance can be cancelled. In practical applications, the cloud gaming client resource scheduling center prioritizes scheduling resource instances not in the shared resource pool, and secondly schedules resource instances that are idle in the shared resource pool.

[0062] Based on this, in one embodiment, the method further includes: When the occupancy rate of the game instance falls below the first threshold, a fourth request is received from the second functional node; the fourth request represents a request to cancel the actual occupancy and pre-occupancy status.

[0063] Here, when the utilization rate of the game instance falls below the second threshold, to prevent the impact of a secondary peak in cloud gaming operations, the actual occupancy is not cancelled at this time. When the utilization rate of the game instance falls below the first threshold, the cloud gaming client resource scheduling center sends a request to the shared resource scheduling center to cancel all actual and pre-occupancy states. The shared resource scheduling center then sends a request to the specific cloud gaming client resource scheduling center to release actual and pre-occupancy states. After the pre-occupancy and actual occupancy are released, the resource instance status is set to idle.

[0064] Using the technical solution of this application embodiment, the first functional node generates a challenge task in response to the resource pre-allocation request, sends the challenge task to the third functional node, the third functional node executes the generated challenge task and generates zero-knowledge proof information. When the zero-knowledge proof information is verified by the blockchain node, a pre-allocated resource instance is allocated for the resource pre-allocation request. In this way, the second functional node that initiates the resource pre-allocation request is provided with pre-allocation efficiency proof through blockchain and zero-knowledge proof technology. Only after the blockchain node verifies the information can the pre-allocated resources be allocated, thus preventing false pre-allocation behavior, reducing the vacancy rate of pre-allocated resources, and thereby improving the utilization rate of pre-allocated resources.

[0065] The present application will be described below with reference to application examples.

[0066] Existing technical solutions typically address peak gaming periods in two ways. One is to employ a waiting strategy, allowing users to wait until available resource instances become available before using the service; the other is to use redundant resource instances, where game providers (i.e., cloud gaming providers) purchase or rent an additional batch of resource instances.

[0067] The first approach mentioned above would cause users to wait. However, there are now many games or applications that can take away users' time. While waiting, users may try other games or applications, which could easily lead to the loss of waiting users.

[0068] For the second option mentioned above, game developers need to purchase or lease excess resource equipment (i.e., resource instances) to prepare for resource instance shortages during peak game periods. However, this requires more funds from game developers and increases the game's operating costs.

[0069] This application addresses the issue of resource constraints faced by cloud gaming providers while simultaneously seeking to reduce costs and increase efficiency. It proposes a cloud service resource sharing solution that achieves sufficient resource utilization without requiring investment in hardware resources. The main features include the following: 1. This application addresses the trust issue in resource sharing by leveraging blockchain and zero-knowledge proof technology. A shared resource scheduling center dynamically generates three-dimensional challenge tasks (including verification tasks across rendering, network, and resource computation dimensions). Cloud gaming providers execute these tasks to generate zero-knowledge proofs containing encrypted watermarks, key transmission, and complete hash chains. Only after verification by blockchain nodes can pre-allocated resources be allocated. By introducing cryptographic verification into resource scheduling, this application completely eliminates fraudulent pre-allocation, significantly improving resource utilization.

[0070] 2. Based on the pre-occupancy request parameters, basic parameters are extracted, dynamic parameters are generated according to the dynamic adjustment strategy table, and then a chaotic sequence derived from the latest block hash value of the blockchain is injected to make the task parameters fluctuate within a set range. Finally, a unique Merkle root Task_ID is generated for each task, and a binary visual watermark is implanted to achieve the unpredictability of the task and full-link traceability.

[0071] 3. When the instance occupancy rate (i.e. the occupancy rate of game running instances) exceeds the first threshold, a shared resource preparation request is triggered to the shared resource scheduling center. After verification by PoPE, the idle resource instance is locked in the pre-occupancy state. When the instance occupancy rate reaches the second threshold, it is upgraded to an uncancellable real-occupancy state. Only when the instance occupancy rate falls back below the first threshold will a request to cancel real-occupancy or pre-occupancy be sent to the shared resource scheduling center to avoid the impact of secondary peaks.

[0072] This application proposes a method for sharing resources on cloud gaming instance sides, including a cloud gaming instance resource scheduling center applying to join a shared resource service. The application to join the shared resource service mainly involves the interaction between two roles: the cloud gaming instance resource scheduling center and the shared resource scheduling center. The cloud gaming instance resource scheduling center is a functional component responsible for scheduling cloud gaming instances. When a user initiates a game execution command on the cloud gaming client, the cloud gaming instance resource scheduling center is responsible for scheduling the instances running the game. The cloud gaming instance resource scheduling center mentioned in this paper refers to this concept and will not be elaborated further.

[0073] Figure 3This is a schematic diagram illustrating the process by which the cloud gaming client resource scheduling center applies to join (i.e. requests to join) the shared resource service, as described in this application embodiment. Figure 3 As shown, the main process is as follows: The cloud gaming resource scheduling center sends a request to the shared resource scheduling center to join the shared resource service. The shared resource scheduling center receives the request, obtains the resource information of the device applying to join the sharing, records the applicant's sharing information, and plans its scalability parameters (i.e., it calculates the additional resources that can be used at peak times based on the shared resource information provided. For example, if an applicant provides GPU resources that can provide 20,000 trillion operations per second (TOPS), then it can share an additional 20,000 to 30,000 TOPS of computing power). The shared resource scheduling center dynamically balances the devices in the shared resource pool, performs secondary cloudification of the game on the shared devices (i.e., installing the game package on some hosts that do not have the game package), and the shared resource scheduling center successfully registers the application to join the shared resource service.

[0074] In practical applications, the cloud gaming client resource scheduling center can also apply for updates (such as modifications) to shared resource instances. Figure 4 This is a schematic diagram illustrating the process of the cloud gaming client resource scheduling center applying for an update of a shared resource instance, as described in this application embodiment. Figure 4 As shown, the main process is as follows: The cloud gaming client resource scheduling center sends a request to the shared resource scheduling center to modify the resource sharing information. The shared resource scheduling center receives the request and verifies the legality of the application information. If the legality verification is successful, it obtains the device resource information to be modified, records the applicant's sharing information, plans its scalability parameters, dynamically balances the devices in the shared resource pool, performs secondary cloudification of the shared devices for gaming, and the shared resource scheduling center successfully registers the application to modify the resource sharing information.

[0075] Figure 5 This is a schematic diagram illustrating the process of the cloud gaming client resource scheduling center requesting to exit the shared resource service, as described in this application embodiment. Figure 5 As shown, the main process is as follows: the cloud gaming resource scheduling center sends a request to the shared resource scheduling center to withdraw from the shared resource service; the shared resource scheduling center receives the request to withdraw from the shared resource service, dynamically balances the devices in the shared resource pool, performs secondary cloudification of the shared devices, and the shared resource scheduling center successfully registers and applies to withdraw from the shared resource service.

[0076] The method for the cloud gaming client resource scheduling center to apply for shared resource services involves two thresholds (including a first threshold and a second threshold). The first threshold is the threshold set by the cloud gaming operator for the pre-allocation of shared resources. When the ratio of the number of running cloud gaming instances to the total number of cloud gaming instances purchased or leased by the cloud gaming operator (i.e., the occupancy rate of running game instances) reaches the first threshold, the cloud gaming client resource scheduling center initiates a shared resource preparation request to the shared resource scheduling center. The shared resource scheduling center obtains the latest status of shared resource instances with installed cloud gaming packages and filters out resource instances that are not idle. At this time, it selects C resource instances. The C value is calculated based on the contribution value of the shared resource instances of the game, multiplied by the first threshold coefficient configured by the shared resource scheduling center. If there are fewer than C available resource instances, the actual number of available resource instances is used. The shared resource scheduling center initiates a pre-allocation request to the cloud gaming scheduling center corresponding to the resource instance. The cloud gaming scheduling center parses the received pre-allocation request and marks the resource instances in the request as pre-allocated. The pre-allocation mark is the cloud gaming identifier of the running game requested for pre-allocation.

[0077] For resource instances in a pre-reserved state, there are two scenarios where the pre-reservation can be cancelled: first, if the instance is not actually reserved or run within the set time, the pre-reservation status is cancelled; second, if the current game's scheduling center has no other available resource instances, the pre-reservation status of the cloud gaming operator's resource instance can be cancelled. The cloud gaming scheduling center prioritizes scheduling resource instances not in the shared resource pool, and then schedules resource instances that are idle in the shared resource pool.

[0078] Regarding resource pre-allocation, the traditional pre-allocation mechanism has a high resource vacancy rate. Due to self-interest or the fear that other vendors will occupy the resources and they will not be able to use them, cloud gaming vendors often pre-allocate more resources, but the actual utilization rate is not very high. In response to this situation, this application proposes a PoPE-based approach to solve the problem.

[0079] The shared resource scheduling center receives a pre-allocation request from the cloud gaming scheduling center, generates a challenge task generator, and starts a performance test task. It generates challenge tasks from the rendering dimension, network dimension, and resource computing dimension, respectively. The cloud gaming provider executes the generated challenge tasks and generates a zero-knowledge proof. If the zero-knowledge proof is verified by the blockchain node's contract, the pre-allocated resources are allocated; otherwise, the request is rejected. Figure 6 A flowchart illustrating the resource allocation method in an embodiment of this application. Figure 2 This method is based on the PoPE process, such as... Figure 6 As shown, the method includes the following steps: Step 1: The cloud gaming scheduling center initiates a resource pre-allocation request (i.e., resource pre-allocation application) to the shared resource scheduling center.

[0080] Step 2: The shared resource scheduling center generates challenge tasks based on the resource pre-allocation request initiated by the cloud gaming scheduling center.

[0081] Here, the challenge tasks include rendering verification tasks, network verification tasks, and resource computation verification tasks, which can be generated based on the requested resources. Each verification task can be mapped to the actual resource capabilities, and the actual performance of the resources can be inferred from the results of executing the task.

[0082] Step 3: The shared resource scheduling center sends the generated challenge tasks to the cloud gaming provider's nodes.

[0083] Step 4: The cloud gaming provider's node receives the challenge task and executes it. Once the task is completed, a zero-knowledge (ZK) proof is generated based on the execution result, and the zero-knowledge proof is synchronized to the blockchain node in the blockchain network.

[0084] Here, to ensure the authenticity of the task execution, an authenticity verification certificate is added to the verification task execution: The rendering verification task is executed, embedding an encrypted watermark in the frequency domain and encrypting the watermark using a challenge key; The network verification task is executed, and data transmission is tested in a real network using the key specified in the challenge task. The resource computation verification task is executed by calculating the entire hash chain through the state hash chain without skipping any computation steps, and then outputting the computation result.

[0085] Step 5: The blockchain node verifies the zero-knowledge proof and obtains the verification result.

[0086] Step 6: The shared resource scheduling center queries the verification results of the blockchain nodes.

[0087] Step 7: If the verification result is successful, the shared resource scheduling center will allocate reserved resources to the reserved request; otherwise, it will not allocate reserved resources to the reserved request, and the process will end.

[0088] The generation of challenge tasks for the shared resource scheduling center can be accomplished by a challenge task generator. Figure 7 This is a schematic diagram illustrating the challenge task generation process in an embodiment of this application, such as... Figure 7 As shown, the generation process of this challenge task mainly includes the following steps: Step S701: Receive the pre-occupancy request and parse the resource type.

[0089] The pre-allocation request includes the following parameters: cloud gaming vendor identifier (vendor_id); requested resource type (resource_type); hardware resource type (hard_type); quality of service requirements (QoS); and pre-allocation market duration.

[0090] The validity of the parameters contained in the pre-reservation request is verified, and the base parameter is extracted based on the requested resource type.

[0091] Step S702: Dynamic parameter adjustment.

[0092] Using the basic parameters extracted in step S701 as input, and based on the preset dynamic adjustment strategy table and trigger conditions, the dynamic parameters of the test task are generated. An example is shown in Table 1 below:

[0093] Table 1 Step S703: Generate fluctuation parameters.

[0094] To enhance the unpredictability of the test tasks, chaotic parameters (i.e., fluctuation parameters) need to be generated and injected into the challenge tasks. These chaotic parameters are obtained by acquiring the hash value of the latest block from the blockchain, using this hash value as a chaotic sequence, and then applying this chaotic sequence to the dynamic parameters. These chaotic parameters fluctuate chaotically within a specific range.

[0095] Step S704: Assemble the task to generate a challenge task.

[0096] The basic and dynamic parameters generated through the above steps serve as the foundational testing dimensions to generate original challenge task test cases. For each task, a task identifier (i.e., Task_Id) is generated using a specific data object in a Merkle tree manner, serving as the task's DNA. The binary sequence of this task is then used as a visual watermark, embedded, and rendered into the challenge task.

[0097] For task verification, the PoPE verification node receives the submission frame and performs comprehensive verification using the embedded watermark and metadata information to obtain the authenticity of the task execution and determine whether the verification is successful.

[0098] Specifically, first, the visual watermark is extracted, and the task ID is reconstructed. This ID is generated using a Merkle tree, and its consistency is verified. Second, the metadata watermark is parsed to verify temporal continuity. When cloud gaming providers execute challenge tasks, they need to interact with a time server to obtain the start and end signature timestamps and embed this parameter into the metadata, such as... Figure 2 The process is illustrated below. The verification node parses the metadata watermark, obtains the timestamp information from the metadata, and verifies the correctness of the timestamp data and the continuity of time.

[0099] The second threshold is the threshold for actual occupancy of shared resources set by the cloud gaming operator. When the occupancy rate of the game running instances reaches the second threshold, the number of cloud game instances that can run is almost exhausted. At this time, the game scheduling center initiates an instance occupancy request to the shared resource scheduling center, and the shared resource scheduling center initiates a device occupancy request to the game scheduling center where the pre-occupied device is located. The occupancy status cannot be passively canceled; it can only be canceled by the shared resource scheduling center.

[0100] When the cloud game scheduling center has no more scheduled resource instances, it sends a game run request to the shared resource scheduling center. At this time, the cloud game's resource scheduling function is forwarded from the game's resource scheduling center to the shared resource scheduling center for processing. The shared resource scheduling center then schedules the occupied instance to render the game, and the running game instance is set to the running state. For instances in the running state, the game terminal is automatically released only after the user terminal finishes the game, and the instance state is set to the idle state after release.

[0101] When instances owned by the game operator become idle, the game scheduling center prioritizes scheduling its own idle instances for game rendering. When the cloud game instance drops below the second threshold, to prevent a secondary surge in game execution, the occupied instances are not cancelled at this time. When the instance drops below the first threshold, a request to cancel all occupied and pre-occupied states is sent to the shared resource scheduling center. The shared resource scheduling center then sends requests to the specific game scheduling center to release occupied and pre-occupied states. After the pre-occupied and occupied states are released, the resource instance status is set to idle.

[0102] The cloud gaming resource instance sharing method proposed in this application needs to be deployed separately in the cloud gaming client resource scheduling center and the shared resource scheduling center. Figure 8 This is a schematic diagram of a device for sharing cloud gaming resource instances according to an embodiment of this application, such as... Figure 8 As shown, the modules deployed in the cloud gaming resource scheduling center can include a resource instance registration client module, a resource instance dynamic monitoring module, and a shared scheduling processing module. The functions of each module are as follows: The resource instance registration client module is responsible for managing the shared services of resource instances for this cloud game, such as applying to join the resource sharing service, leaving the resource sharing service, updating and adjusting the device information of the shared service, and providing a service to query the hardware information of the cloud game's resource devices.

[0103] The resource instance dynamic monitoring module is responsible for monitoring changes in the running instances of this cloud game. When the number of running instances changes upward or downward, it triggers resource request requests at the first and second thresholds, respectively.

[0104] The shared scheduling processing module is responsible for receiving and processing requests from the shared resource scheduling center regarding changes to the status of the cloud game resource instance, as well as proactively canceling the pre-reservation status of the cloud game and synchronizing the instance status to the shared resource scheduling center.

[0105] The modules deployed in the shared resource scheduling center may include the following modules: registration management server module, shared instance resource balancing module, and shared instance scheduling and allocation module. The functions of each module are as follows: The registration management server module is responsible for receiving information such as resource instance registration, exit, and update initiated by the cloud gaming client resource scheduling center, and for maintaining the resource instance information list and dynamically maintaining changes to resource instances.

[0106] The shared instance resource balancing module is responsible for controlling the installation of cloud game packages on shared instances and dynamically adjusting the game packages installed on resource instances based on the status of all instances in the shared resource pool.

[0107] The shared instance scheduling and allocation module is responsible for receiving and processing requests for the pre-occupancy, actual occupancy, and startup of resource instances initiated by the cloud gaming resource scheduling center, as well as receiving and processing requests for status changes such as pre-occupancy and actual occupancy of shared resource instances initiated by other game operators, and for receiving and processing shared resource usage requests.

[0108] Taking cloud gaming A as an example, Figure 9 This is a schematic diagram illustrating the process of a cloud gaming client resource scheduling center requesting the use of shared resources, as described in an embodiment of this application. Figure 9 As shown, the process mainly includes the following specific steps: S901: Cloud Game A has joined the shared resource service. At a certain moment, the number of online running instances is gradually increasing. When the proportion of running instances of Cloud Game A reaches the preset first threshold, a request is triggered, as in S902.

[0109] S902: When the number of running instances of cloud game A increases from low to high and triggers the reaching of the preset first threshold, the resource scheduling center of cloud game A sends a resource instance pre-occupancy request to the shared resource scheduling center to pre-occupy and estimate the available shared resources.

[0110] S903: The shared resource scheduling center receives a pre-occupancy request from the game scheduling center, performs PoPE verification on the pre-occupancy request, and terminates the process directly if the verification fails; if the verification succeeds, it performs statistics and planning on the shared resource instances whose resource instance status is idle, and initiates a pre-occupancy request to the game scheduling center where the idle shared resource instance is located.

[0111] S904: If the game scheduling center receives a pre-reservation request in S903, it checks the status of the device in the resource instance pool in the request. If the device is in an idle state, it sets the current instance status to pre-reservation, records the game ID of the pre-reserved game, and returns a pre-reservation success message. If the device is not in an idle state, it returns a pre-reservation failure message.

[0112] S905: When the number of running instances of cloud game A increases from low to high and triggers the preset second threshold, the cloud game A scheduling center sends a resource instance reallocation request to the shared resource scheduling center to prepare for the use of shared resource instances before running.

[0113] S906: The shared resource scheduling center receives a resource allocation request from the cloud game A scheduling center and initiates an allocation request to the game-side scheduling center where the pre-allocated shared resource instance is located. Upon receiving the resource allocation request from the shared resource scheduling center, the game-side scheduling center first checks the status of the resource instances in its resource pool. If the instance is in a pre-allocated state, it changes the instance's status to allocated and returns a success message; otherwise, it returns a failure message.

[0114] S907: When there are no available resource instances in the resource scheduling center of cloud game A, the current scheduling center will forward the scheduling task to the shared resource scheduling center, which will then schedule the resources of cloud game A.

[0115] Figure 10 This is a schematic diagram illustrating the interaction of scheduling shared resources according to an embodiment of this application, such as... Figure 10 As shown, since all resource instances in the resource pool of cloud game A are occupied, the scheduling task is forwarded from the resource scheduling center of cloud game A to the shared resource scheduling center. That is, the shared resource scheduling center schedules the resources of cloud game A, specifically, it schedules unoccupied resource instances from the shared resource pool.

[0116] S908: The shared resource scheduling center schedules resource instances in the shared resource pool whose instance status is "fully occupied" and whose occupied package ID is the package ID of cloud game A. The scheduled resource instance renders cloud game A, establishes a communication connection with the user's terminal device, receives operation commands (also known as control commands or game commands) sent by the user, processes the game commands, and pushes the rendering results (such as game screen streaming) to the user's terminal device. Figure 11 As shown.

[0117] S909: The scheduling center where the scheduled resource instance is located receives the game running request sent by the shared resource scheduling center. First, it checks the current instance status. If it is in an occupied state, it receives the request instruction, modifies the instance status to a non-own game running state, and returns success; otherwise, it returns failure.

[0118] S910: When a cloud gaming instance finishes running, its game-side resource scheduling center sets its status to idle and synchronizes the instance's status information with the shared resource scheduling center. When there are idle resource devices in the resource pool of cloud game A, the resource scheduling center of cloud game A will prioritize using the idle resources (i.e., idle devices) in its resource pool, and the shared resource scheduling center will also prioritize scheduling idle devices in the resource pool of cloud game A.

[0119] To implement the resource allocation method of this application embodiment, this application embodiment also provides a resource allocation device, which is disposed in the first functional node. Figure 12 This is a schematic diagram of the composition structure of the resource allocation device according to an embodiment of this application, as shown below. Figure 12 As shown, the resource allocation device includes: The first receiving unit 1201 is used to receive a first request sent by the second functional node; the first request represents a resource pre-occupancy request. The first generation unit 1202 is used to generate a challenge task in response to the first request; The sending unit 1203 is used to send the challenge task to the third functional node, so that the third functional node generates first information based on the challenge task and synchronizes the first information to the blockchain network; the first information represents zero-knowledge proof information. The allocation unit 1204 is used to allocate a pre-reserved resource instance to the first request when the blockchain node in the blockchain network verifies the first information.

[0120] In one embodiment, the first generation unit 1202 includes a second generation unit, a third generation unit, and a fourth generation unit; wherein, The second generation unit is configured to generate basic parameters based on the first request in response to the first request; The third generation unit is used to generate dynamic parameters based on the basic parameters; The fourth generation unit is used to generate the challenge task based on the basic parameters and the dynamic parameters.

[0121] In one embodiment, the third generating unit is specifically used for: Retrieve the preset dynamic adjustment strategy table; The dynamic parameters are generated based on the basic parameters and the dynamic adjustment strategy table.

[0122] In one embodiment, the fourth generation unit is specifically used for: Obtain the chaotic sequence; The chaotic sequence is applied to the dynamic parameters to generate chaotic parameters; The challenge task is generated based on the basic parameters and the chaos parameters.

[0123] In one embodiment, the challenge task includes one or more of the following information: Task identification information; First watermark information; the first watermark information represents visual watermark information obtained based on the binary sequence of the challenge task; Second watermark information; the second watermark information represents the metadata watermark information of the challenge task, and the metadata watermark information includes the timestamp information in the metadata of the challenge task.

[0124] In one embodiment, the resource allocation device further includes: a second receiving unit; wherein, The second receiving unit is used to receive a second request sent by the second functional node when the occupancy rate of the game running instance reaches a preset first threshold. The second request represents a shared resource preparation request, and the second request is a prerequisite request for the first request.

[0125] In one embodiment, the resource allocation device further includes: a third receiving unit; wherein, The third receiving unit is used to receive a third request sent by the second functional node when the occupancy rate of the game running instance reaches a preset second threshold; the third request represents a resource occupancy request.

[0126] In practical applications, the first receiving unit 1201 and the sending unit 1203 can be implemented by the communication interface in the resource allocation device; the first generating unit 1202 and the allocation unit 1204 can be implemented by the processor in the resource allocation device.

[0127] It should be noted that the resource allocation device provided in the above embodiments is only illustrated by the division of the above program modules. In actual applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the device can be divided into different program modules to complete all or part of the processing described above. In addition, the resource allocation device and the resource allocation method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the resource allocation method embodiments, which will not be repeated here.

[0128] Based on the hardware implementation of the above program modules, and in order to implement the resource allocation method of this application embodiment, this application embodiment also provides a resource allocation device, which can be a first functional node. Figure 13This is a schematic diagram of the hardware composition structure of the resource allocation device according to an embodiment of this application, as shown below. Figure 13 As shown, the resource allocation device 1300 includes: The communication interface 1301 is capable of exchanging information with other devices (such as second functional nodes and third functional nodes); The processor 1302 is connected to the communication interface 1301 to enable information interaction with other devices. When running a computer program, it executes the resource allocation method provided above, and the computer program is stored in the memory 1303.

[0129] It should be noted that the specific processing procedures of communication interface 1301 and processor 1302 can be understood by referring to the resource allocation method described above.

[0130] Of course, in practical applications, the various components in the resource allocation device 1300 are coupled together through the bus system 1304. It can be understood that the bus system 1304 is used to implement communication between these components. In addition to a data bus, the bus system 1304 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 13 The general designated all buses as Bus System 1304.

[0131] The memory 1303 in this embodiment is used to store various types of data to support the operation of the resource allocation device 1300. Examples of such data include any computer program used to operate on the resource allocation device 1300.

[0132] The resource allocation method disclosed in the above embodiments of this application can be applied to the processor 1302, or implemented by the processor 1302. The processor 1302 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above resource allocation method can be completed by the integrated logic circuit of the hardware in the processor 1302 or by instructions in the form of software. The processor 1302 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor 1302 can implement or execute the various resource allocation methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the resource allocation method disclosed in the embodiments of this application can be directly reflected as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in the memory 1303. The processor 1302 reads the information in the memory 1303 and completes the steps of the aforementioned resource allocation method in combination with its hardware.

[0133] In an exemplary embodiment, the resource allocation device 1300 may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned resource allocation method.

[0134] It is understood that the memory 1303 in this embodiment can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memory 1303 described in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0135] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a memory 1303 storing a computer program. This computer program can be executed by a processor 1302 in the resource allocation device 1300 to complete the steps of the resource allocation method described in the foregoing embodiments of this application. The computer-readable storage medium can be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM.

[0136] In an exemplary embodiment, this application also provides a computer program product, including a computer program that can be executed by a processor 1302 in a resource allocation device 1300 to complete the steps of the resource allocation method described in the foregoing embodiments of this application.

[0137] It should be noted that terms such as "first," "second," and "third" are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0138] Furthermore, the technical solutions described in the embodiments of this application can be combined arbitrarily without conflict.

[0139] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A resource allocation method, characterized in that, Applied to the first functional node, the method includes: Receive a first request sent by the second functional node; the first request represents a resource pre-allocation request. In response to the first request, a challenge task is generated; The challenge task is sent to a third functional node, which generates first information based on the challenge task and synchronizes the first information to the blockchain network; the first information represents zero-knowledge proof information. When a blockchain node in the blockchain network verifies the first information, it allocates a pre-reserved resource instance to the first request.

2. The method according to claim 1, characterized in that, The step of generating a challenge task in response to the first request includes: In response to the first request, basic parameters are generated based on the first request; Based on the aforementioned basic parameters, dynamic parameters are generated; The challenge task is generated based on the basic parameters and the dynamic parameters.

3. The method according to claim 2, characterized in that, The generation of dynamic parameters based on the basic parameters includes: Retrieve the preset dynamic adjustment strategy table; The dynamic parameters are generated based on the basic parameters and the dynamic adjustment strategy table.

4. The method according to claim 2, characterized in that, The process of generating the challenge task based on the basic parameters and the dynamic parameters includes: Obtain the chaotic sequence; The chaotic sequence is applied to the dynamic parameters to generate chaotic parameters; The challenge task is generated based on the basic parameters and the chaos parameters.

5. The method according to any one of claims 1 to 4, characterized in that, The challenge task includes one or more of the following information: Task identification information; First watermark information; the first watermark information represents visual watermark information obtained based on the binary sequence of the challenge task; Second watermark information; The second watermark information represents the metadata watermark information of the challenge task, and the metadata watermark information includes the timestamp information in the metadata of the challenge task.

6. The method according to claim 1, characterized in that, The method further includes: When the occupancy rate of the game instance reaches a preset first threshold, a second request is received from the second functional node; The second request represents a shared resource preparation request, and the second request is a prerequisite request for the first request.

7. The method according to claim 6, characterized in that, The method further includes: When the utilization rate of the game instance reaches a preset second threshold, a third request is received from the second functional node; the third request represents a resource occupancy request.

8. A resource allocation device, characterized in that, include: A processor and a memory for storing computer programs capable of running on the processor; When the processor is used to run the computer program, it performs the steps of the method according to any one of claims 1 to 7.

9. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images