Method, device, medium and equipment for generating call link

Abstract

The application relates to a method, device, medium and equipment for generating a calling link. The method for generating a calling link is applied to a node and comprises the following steps: receiving an API request; parsing header information of the API request to determine whether link data exists, wherein the link data comprises a hop count, a maximum allowed hop count and a historical node information array; if the link data exists, performing validity verification on the historical node information array; if the historical node information array is valid, performing loop detection; if no loop exists, adding node information of a current node to the historical node information array; and updating the hop count, and forwarding the API request to a next node when the hop count is less than the maximum allowed hop count. The method can detect the calling link in real time, prevent loop occurrence and be easily deployed in a distributed environment.

Description

Technical Field

[0001] This application relates to the field of AI large model invocation technology, and in particular to a method, apparatus, medium and device for generating invocation links. Background Technology

[0002] In systems where multiple microservices call each other, the existence of call loops can lead to a chaotic system architecture and affect the reliability of the entire service. Especially with the development of artificial intelligence technology, in distributed AI large-scale model calling scenarios, significant differences exist between different nodes in model versions (such as parameter size and training version) and inference capabilities (such as computing resources and response latency). Ensuring the technical consistency of call paths (i.e., ensuring that requests are routed to the most suitable model node) and preventing routing information from being tampered with during forwarding have become urgent technical problems that need to be solved to guarantee the quality of large-scale model services.

[0003] However, for the above scenarios, traditional technologies still have the following problems: API call loop detection is inaccurate. It generally relies on a simple timeout mechanism to detect whether a loop has occurred. It can only be detected passively after a loop has formed, and cannot prevent the occurrence of loops in real time. API proxy link information is not transparent, intermediate nodes cannot know the complete call path, and there is a lack of effective call link auditing mechanism; The call chain has insufficient security, the chain information is easily tampered with, the integrity of the call chain cannot be verified, and it is difficult to prevent attacks from malicious nodes. Centralized monitoring poses a single point of failure risk, is difficult to deploy in a distributed environment, results in significant resource waste, and cannot effectively prevent problems from occurring. Summary of the Invention

[0004] To overcome the problems existing in related technologies, this application provides a method, apparatus, medium and device for generating call links.

[0005] According to a first aspect of the embodiments of this application, a method for generating a call chain is provided, applied to a node, comprising: Receive API requests; Parse the header information of the API request to determine whether there is link data, which includes the number of hops, the maximum allowed number of hops, and an array of historical node information; If link data exists, the validity of the historical node information array is verified; If the historical node information array is valid, perform loop detection; If no loop exists, add the current node's node information to the historical node information array; Update the hop count. If the hop count is less than the maximum allowed hop count, forward the API request to the next node.

[0006] In some embodiments of this application, based on the foregoing scheme, the method for generating call chains further includes: If the link data does not exist, create the link data. Generate a unique link identifier, set the maximum allowed number of hops, and add the current node's node information to the historical node information array.

[0007] In some embodiments of this application, based on the aforementioned scheme, the node information includes: a unique provider identifier, a timestamp of receiving the request, and a geolocation code; The node information of multiple nodes in the historical node information array is stored in chronological order.

[0008] In some embodiments of this application, based on the foregoing scheme, adding the node information of the current node to the historical node information array includes: When the node is the first node, generate the signature of the current node; Add the node information and signature of the current node to the historical node information array; If the node is not the first node, generate the signature of the current node; Obtain the signatures of historical nodes, and generate an aggregated historical signature based on the signatures of the current node and the historical nodes; Add the node information of the current node and the aggregated historical signature to the historical node information array.

[0009] In some embodiments of this application, based on the foregoing scheme, after adding the node information of the current node to the historical node information array and updating the hop count, the method further includes: generating a link integrity hash and adding it to the link data.

[0010] In some embodiments of this application, based on the foregoing scheme, the loop detection includes: Iterate through the information of all nodes in the historical node information array. If a node has two unique provider identifiers, it is determined that there is a loop in the link; or, if the unique provider identifier of the current node exists in the historical node information array, it is determined that there is a loop in the link.

[0011] According to another aspect of the embodiments of this application, a call chain generation apparatus is provided, applied to a node, comprising: The request receiving module is used to receive API requests; The parsing module is used to parse the header information of the API request and determine whether there is link data. The link data includes the number of hops, the maximum allowed number of hops, and an array of historical node information. The verification module is used to verify the validity of the historical node information array if link data exists. The detection module is used to perform loop detection if the historical node information array is valid. The node information writing module is used to add the node information of the current node to the historical node information array if there is no loop. The forwarding module is used to update the hop count. When the hop count is less than the maximum allowed hop count, the API request is forwarded to the next node.

[0012] In some embodiments of this application, based on the foregoing scheme, the parsing module is further configured to: create link data if no link data exists; The node information writing module is also used to: generate a unique link identifier, set the maximum allowed number of hops, and add the node information of the current node to the historical node information array.

[0013] In some embodiments of this application, based on the foregoing scheme, the node information writing module is further configured to: When the node is the first node, generate the signature of the current node; Add the node information and signature of the current node to the historical node information array; If the node is not the first node, generate the signature of the current node; Obtain the signatures of historical nodes, and generate an aggregated historical signature based on the signatures of the current node and the historical nodes; Add the node information of the current node and the aggregated historical signature to the historical node information array.

[0014] In some embodiments of this application, based on the foregoing scheme, the forwarding module is further configured to: Generate a link integrity hash and add it to the link data.

[0015] In some embodiments of this application, based on the foregoing scheme, the detection module is further configured to: Iterate through the information of all nodes in the historical node information array. If a node has two unique provider identifiers, it is determined that there is a loop in the link; or, if the unique provider identifier of the current node exists in the historical node information array, it is determined that there is a loop in the link.

[0016] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, wherein when the computer program is executed, the steps of a method for generating a call chain are implemented.

[0017] According to another aspect of the embodiments of this application, a computer device is provided, including a processor, a memory, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of a call chain generation method.

[0018] The method for generating call chains in this application involves a node receiving an API request, parsing the API request header information, and obtaining the chain data, which includes an array of historical node information. The current node performs security verification on the historical node information array and the chain data, and performs loop detection. If no loop is found, the current node's node information is added to the historical node information array, the chain data is updated, and the data is sent to the next node. This method enables real-time detection of the call chain, preventing loops, and the information of previously called historical nodes is transparent to the current node, enabling chain auditing. The detection and auditing of the chain are performed by the node receiving the request, making it easy to deploy in a distributed environment.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0021] Figure 1 This is a flowchart illustrating a method for generating a call chain according to an exemplary embodiment.

[0022] Figure 2 This is a block diagram of a call chain generation apparatus according to an exemplary embodiment.

[0023] Figure 3 This is a block diagram illustrating a computer device according to an exemplary embodiment. Detailed Implementation

[0024] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0025] Traditional technologies suffer from several drawbacks, including inaccurate API call loop detection, inability to prevent loops in real time, opaque API proxy link information (intermediate nodes cannot understand the complete call path, lack of effective call link auditing mechanisms), insufficient call link security (link information is easily tampered with, inability to verify the integrity of the call link, and difficulty in preventing malicious node attacks), and centralized monitoring has the risk of single point of failure, is difficult to deploy in a distributed environment, results in serious resource waste, and cannot effectively prevent problems from occurring. This application provides a method for generating call links.

[0026] Figure 1 This is a flowchart illustrating a method for generating a call chain according to an exemplary embodiment. (See reference) Figure 1 The link generation method is applied to nodes, including: Step S11: Receive API request.

[0027] Nodes can belong to different providers. They can be nodes directly requested by users or nodes invoked by other nodes. Therefore, the API requests received by a node can be API requests sent by users to the node or API requests forwarded by other nodes.

[0028] Step S12: Parse the header information of the API request to determine whether there is link data. The link data includes the number of hops, the maximum allowed number of hops, and an array of historical node information.

[0029] When a node receives an API request, it can parse the request header information to determine whether link data exists.

[0030] In this application, the link data is created by the first node to receive the user request. That is, the first node to receive the API request will not have link data in the request header. Based on this, the node can determine whether link data exists by parsing the API request header, thus determining whether the node itself is the first node to receive the user request or an intermediate node.

[0031] In one exemplary embodiment, if link data does not exist, link data is created; Generate a unique link identifier, set the maximum allowed hop count, and add the current node's information to the historical node information array. If no link data exists, the current node can be identified as the first node to receive the user request, and the link data will be created by that node.

[0032] Parse the API request header information. If no link data exists, it means that this node is the first node to receive the user request, that is, the first API provider node in the entire call chain. The link data is then created by the first API provider node.

[0033] Link data can be created based on a preset data structure.

[0034] For example, the data structure of link data can be in the following format: { "cid": "UUID", "v": "", "h": 0, "mh": 8, "n": [ ], } This data structure includes the following fields: cid: Link unique identifier, which is a UUID (Universally Unique Identifier) ​​generated by the first provider node. It is globally unique and used to identify the entire call link. Subsequent nodes will not regenerate it.

[0035] v: Protocol version number, which identifies the current link tag protocol version and is used for forward compatibility and protocol upgrades.

[0036] h: Current hop count, representing the total number of nodes the link has passed through - incremented by 1 for each proxy node passed through, which can be used for loop detection and performance analysis.

[0037] mh: Maximum allowed hops, the upper limit of hops set by the first provider to prevent the link from extending indefinitely.

[0038] n: A historical node information array containing detailed information about all nodes in the link, stored in chronological order, used for loop detection and link tracing, represented as: [{node1}, {node2}, ...]. The node information for each node is added to the node information array as an object. It is worth noting that the historical node information array is empty when the first node to receive a user request creates link data.

[0039] Each node object (node ​​information) can be: { "pid": "provider1-us", "t": 1673456789, "geo": "US-EAST", "sig": "SHA256-BASE64-SIGNATURE" } A node object contains the following fields: PID: A unique identifier for the node provider. It uses the standard name officially declared by the provider and is globally unique. It is used for loop detection.

[0040] t: Unix timestamp, the precise time the node received the request, with second-level precision. Used for timing verification and performance analysis.

[0041] geo: Geographic location code, which is a standardized identifier for the geographic region where the node is located. It is used for geographic routing optimization and adopts an intercontinental-regional format.

[0042] Sig: Digital signature, a node's private key signature of its own information, encoded using SHA256+BASE64, used for tamper-proofing and authentication.

[0043] After parsing the request header information, if the current node contains link data, it means that the current node is not the first node to receive the user request. If the link data does not exist, it means that the current node is the first node to receive the user request.

[0044] Step S13: If link data exists, verify the validity of the historical node information array.

[0045] After receiving an API request, a node that is not the first to receive a user request can verify the validity of the parsed link data. For example, it can verify the digital signatures of each node object in the historical node information array. A digital signature is a signature of a node's own information using its private key, and can be used for tamper prevention and authentication. The current node can verify the information based on the digital signatures of nodes existing in the historical node information array. For example, the current node can obtain the public key of the corresponding historical node, verify the digital signature, and determine whether the information of the historical nodes in the historical node information array is accurate and valid, preventing data tampering.

[0046] Step S14: If the historical node information array is valid, perform loop detection.

[0047] If the historical node information array is valid, based on the node information recorded in the array, the current node can know which nodes the data link passes through, which provider each node belongs to, its geographical location, and the specific time it received the API request. This allows for loop detection of the link.

[0048] Step S15: If there is no loop, add the node information of the current node to the historical node information array.

[0049] If no loop exists, determine if the current node meets the forwarding conditions. If it does, determine that the API request needs to be forwarded. Add the current node's information to the historical node information array so that subsequent nodes can determine the forwarding path for the API request based on the information recorded in the historical node information array.

[0050] In one exemplary embodiment, the forwarding condition includes: the current node is not the optimal node.

[0051] For example, if the current node is not the optimal node because the load on the large model is high and it is difficult to provide quality service, the API request will be forwarded to the next node when the current hop count is less than the maximum allowed hop count. This allows subsequent nodes to send API requests to the large model with a lower load, thereby improving service quality.

[0052] For example, the current node may have a low load on the large model, but the cost of calling the large model corresponding to the current node in the current time period is $0.012 / 1K tokens. It is known that there are other large models with a cost of $0.003 / 1K tokens in the current time period. The large model corresponding to the current node is not the lowest cost large model. Therefore, it is determined that the current node is not the optimal node. When the current hop count is less than the maximum allowed hop count, the API request is forwarded to the next node so that subsequent nodes can send API requests to the lower cost large model, thereby improving response quality and reducing costs.

[0053] If the API request needs to be forwarded, add the current node's node information to the historical information array and update the link data.

[0054] Forwarding conditions may be adjusted according to actual circumstances; this application does not impose any restrictions.

[0055] If a loop exists, the API request will be rejected and an error response will be returned. Loops should be reported promptly.

[0056] Step S16: Update the hop count. If the hop count is less than the maximum allowed hop count, forward the API request to the next node.

[0057] At the same time, update the hop count in the link data. When the hop count is less than the maximum allowed hop count, forward the API request to the next node.

[0058] When the number of hops equals the maximum allowed hops, the current node no longer considers the load of the corresponding large model or whether the cost is lowest; the current node provides the API service regardless. This ensures that the API request is served before the maximum number of hops is reached, preventing the request from being forwarded indefinitely.

[0059] For example: After the first node to receive a user request creates a data structure, it adds the node information to the historical node information array, updates the hop count, and generates updated link data. { "cid": "550e8400-e29b-41d4-a716-446655440000", "v": "v1", "h": 1, "mh": 8, "n": [ { "pid": "provider1-us", "t": 1673456789, "geo": "US-EAST", "sig": "SHA256-BASE64-SIGNATURE-1" }, ], } In the data structure, "550e8400-e29b-41d4-a716-446655440000" represents the first API provider node (generated universally unique identifier); the hop count "h" is updated from 0 to 1, indicating that a proxy node has been traversed. The node information of the first API provider node is added to the historical node information array as an object. If the current node determines that it is not the optimal node and its current hop count is less than 8, it forwards the API request to the next node.

[0060] After receiving the API request, the second node repeats the above steps: after validating the node information identified as "provider1-us", it adds its own node information to the historical node information array, updates the hop count, and generates updated link data. { "cid": "550e8400-e29b-41d4-a716-446655440000", "v": "v1", "h": 2, "mh": 8, "n": [ { "pid": "provider1-us", "t": 1673456789, "geo": "US-EAST", "sig": "SHA256-BASE64-SIGNATURE-1" }, { "pid": "provider2-eu", "t": 1673456790, "geo": "EU-WEST", "sig": "SHA256-BASE64-SIGNATURE-2" } ], } As the number of API request forwards increases, each accessed node adds its own node information to the historical node information array. The historical node information array can be used to save and record complete link data.

[0061] In this embodiment, after the API request is forwarded to the next node, the next node acts as the current node and checks the information of each node in the historical information array, which can promptly detect loops. Furthermore, the link information is transparent, allowing intermediate nodes to understand the complete call chain and audit it in a timely manner, further preventing loops from occurring.

[0062] In one exemplary embodiment, the node information includes: a unique provider identifier, a timestamp of receiving the request, and a geolocation code; The node information of multiple nodes in the historical node information array is stored in chronological order.

[0063] Each historical node's information includes a timestamp of the received request. By sorting the node information of multiple nodes chronologically, the node information can be stored according to the order in which requests arrived at the nodes. Based on the historical node information array, complete link data can be constructed. Any node that receives a request can know from the historical node information array how many times the request was forwarded, how many nodes it passed through, the specific location of each intermediate node, and its provider, among other information.

[0064] Based on the timestamps of received requests recorded in the information of each node, the transmission delay between different nodes can also be determined, thereby identifying the performance bottleneck of the link and providing data support for route optimization.

[0065] In an exemplary embodiment, step S15, adding the node information of the current node to the historical node information array, includes: When the node is the first node, generate the signature of the current node; Add the node information and signature of the current node to the historical node information array; If the node is not the first node, generate the signature of the current node; Obtain the signatures of historical nodes, and generate an aggregated historical signature based on the signatures of the current node and the historical nodes; Add the node information of the current node and the current aggregated historical signature to the historical node information array.

[0066] Each current node can generate a current node signature based on its own supplier unique identifier, the timestamp of the received request, and the geolocation code. Before forwarding the API request, the node information and the current node signature of the current node are added to the historical node information array.

[0067] For example, nodes can use BLS (Boneh-Lynn-Shacham) signatures, which are a digital signature scheme based on bilinear pairing. The signatures are very short and support signature aggregation (multiple signatures can be combined into one).

[0068] If each node adds its current node information and signature to the historical node information array, after the API request is forwarded to the next node, the next node needs to extract the node's signature from each node object to verify the validity of the data. When there are a large number of nodes, this requires a large amount of computation and time.

[0069] In this embodiment, when the node is the first node, the signature of the current node is generated; the node information of the current node and the signature of the current node are added to the historical node information array.

[0070] When a node is not the first node, after generating the signature of the current node, obtain the signatures of historical nodes, and generate an aggregated historical signature based on the signatures of the current node and the signatures of historical nodes; add the node information of the current node and the aggregated historical signature to the historical node information array.

[0071] Except for the first node, after receiving an API request, other nodes parse the API request header information, obtain the link data, and retrieve the information and signatures of previous historical nodes from the historical node information group in the link data. Starting from the second node, the digital signatures of the second node and the first node are aggregated to generate an aggregated historical signature, which is then added to the historical node information array.

[0072] For example, the link data is: { "cid": "550e8400-e29b-41d4-a716-446655440000", "v": "v1", "h": 2, "mh": 8, "n": [ { "pid": "provider1-us", "t": 1673456789, "geo": "US-EAST", "sig": "SHA256-BASE64-SIGNATURE-1" }, { "pid": "provider2-eu", "t": 1673456790, "geo": "EU-WEST", "sig": "SHA256-BASE64-SIGNATURE-2" } ], } In this link data, "SHA256-BASE64-SIGNATURE-1" is the digital signature of the first node; "SHA256-BASE64-SIGNATURE-2" is the aggregated historical signature of the digital signatures of the first node and the second node.

[0073] When an API request is forwarded to a third node, the third node can obtain the aggregated historical signature from the signature of the second node and verify the validity of all original signatures at once. By aggregating the independent signatures of multiple nodes into a single signature, not only is the bandwidth consumption of the API request header in network transmission significantly reduced, but any subsequent node only needs to execute the aggregation verification algorithm once to complete the identity tracing of the entire historical node, which greatly reduces the consumption of system computing resources in large-scale concurrent API call scenarios.

[0074] Similarly, the third node generates its own digital signature and aggregates it again with the aggregated historical signature of the second node, which becomes the aggregated historical signature of the third node.

[0075] In one exemplary embodiment, after adding the node information of the current node to the historical node information array and updating the hop count, the method further includes: generating a link integrity hash and adding it to the link data.

[0076] After the current node adds its node information to the historical node information array and updates its hop count, a complete link data is formed. A link integrity hash is then generated for the entire link data and added to it. This process protects the entire link data from tampering.

[0077] For example, after the second node adds the node information and aggregated historical signature to the historical node information array, it updates the hop count to 2 and adds the link integrity hash to the end of the link data. The link data is as follows: { "cid": "550e8400-e29b-41d4-a716-446655440000", "v": "v1", "h": 2, "mh": 8, "n": [ { "pid": "provider1-us", "t": 1673456789, "geo": "US-EAST", "sig": "SHA256-BASE64-SIGNATURE-1" }, { "pid": "provider2-eu", "t": 1673456790, "geo": "EU-WEST", "sig": "SHA256-BASE64-SIGNATURE-2" } ], "rh": "SHA256-HASH-OF-ROUTE-HISTORY" } The "rh" field is the link integrity hash, which can effectively prevent tampering of node data by adding or deleting nodes in the link data.

[0078] In an exemplary embodiment, step S14, performing loop detection includes: Traverse the information of all nodes in the historical node information array. If a node has two unique provider identifiers, it is determined that there is a loop in the link; or, if the unique provider identifier of the current node exists in the historical node information array, it is determined that there is a loop in the link.

[0079] Because the historical node information array can be viewed as a collection of historical node information, it allows for constant-time lookup. A single iteration through the array can determine the provider identifier for each historical node. If two unique provider identifiers exist for a given node, it indicates a loop exists in the current link.

[0080] Alternatively, if the provider's unique identifier for the current node exists in the historical node information array, it means that the current node has already been requested, and a loop has been formed.

[0081] Once a loop is detected, the current node can reject the request and return an error response. For example, it can return "has_loop = True" to the requester.

[0082] Since each node performs loop detection upon receiving an API request, it's normal that two identical provider unique identifiers should not exist in the historical node information array. To prevent loops from occurring due to accidental configuration errors or other reasons, this embodiment first iterates through all nodes in the historical node information array to determine if a loop already exists. Then, it checks the current node to determine if its provider unique identifier already exists in the historical node information array, thus preventing loop formation. This approach can prevent loops in real time and proactively detect them before they form, making it a highly efficient loop detection algorithm.

[0083] The method for generating call chains provided in this application will be further described below with specific embodiments. Specific Implementation Example 1 A user sends a request for a large model. The request is sent to a provider node, which is defined as the first node for ease of expression.

[0085] After receiving the API request, the first node parses the API request header information. Since this request is being sent to the provider node for the first time and there is no link data yet, the first node can determine that it is the first node to receive the user request.

[0086] If the first node is the optimal node, it responds to the API request. If the first node is not the optimal node, it generates a unique link identifier, sets the maximum allowed hop count, and creates link data. It uses the node provider's unique identifier, the timestamp of the received request, and the first node's address code as node information to generate a digital signature for the first node, "SHA256-BASE64-SIGNATURE-1". The node information and digital signature are added to the historical node information array as an object, and the current hop count is updated to 1. Finally, it generates a link integrity hash, "SHA256-HASH-OF-ROUTE-HISTORY-1", for the entire link data and adds it to the "rh" field of the link data.

[0087] The link data is as follows: { "cid": "550e8400-e29b-41d4-a716-446655440000", "v": "v1", "h": 1, "mh": 8, "n": [ { "pid": "provider1-us", "t": 1673456789, "geo": "US-EAST", "sig": "SHA256-BASE64-SIGNATURE-1" }, ], "rh": "SHA256-HASH-OF-ROUTE-HISTORY-1" } Add the aforementioned link data to the request header. For example, JSON-encode the complete link data, then base64-encode it before adding it to the request header. Forward the API request to the next node.

[0088] The second node receives the API request forwarded by the first node, parses the X-API-Chain header, and obtains the link data. It verifies data integrity based on the "rh" field and data validity based on the "sig" field.

[0089] If data integrity or validity verification fails, the request is rejected and an error response is returned.

[0090] If data integrity and validity verification are passed, loop detection is performed. The information of all nodes in the historical node information array is traversed. Since the link data at this point only includes information about one node, there is no situation where a node has two provider unique identifiers. The provider unique identifier of the second node is then checked for existence in the historical node information array, and the result is no. Therefore, it is determined that the current link does not have a loop.

[0091] If the second node is also not the optimal node, the second node generates its own digital signature and aggregates it with the first node's digital signature to obtain the second node's aggregated historical signature "SHA256-BASE64-SIGNATURE-2". The second node's node information and the aggregated historical signature are then added to the historical node information array as objects. The hop count is updated to 2.

[0092] The current hop count is not greater than or equal to the maximum allowed hop count.

[0093] Generate a link integrity hash "SHA256-HASH-OF-ROUTE-HISTORY-2" and replace the content of the "rh" field in the link data. Encode the complete link data into JSON, then base64, and append it to the request header. Forward the API request to the next node.

[0094] The link data is as follows: { "cid": "550e8400-e29b-41d4-a716-446655440000", "v": "v1", "h": 2, "mh": 8, "n": [ { "pid": "provider1-us", "t": 1673456789, "geo": "US-EAST", "sig": "SHA256-BASE64-SIGNATURE-1" }, { "pid": "provider2-eu", "t": 1673456790, "geo": "EU-WEST", "sig": "SHA256-BASE64-SIGNATURE-2"} ], "rh": "SHA256-HASH-OF-ROUTE-HISTORY-2" } The third node receives the API request forwarded by the second node, parses the X-API-Chain header, and obtains the link data. It verifies data integrity based on the "rh" field and data validity based on the "sig" field.

[0095] If data integrity and validity verifications are passed, loop detection is performed. The information of all nodes in the historical node information array is traversed. Since the link data at this point only includes the information of the first and second nodes, there is no situation where a node has two provider unique identifiers. The provider unique identifier of the third node is then checked for existence in the historical node information array, and the result is no. Therefore, it is determined that the current link does not have a loop.

[0096] If the third node is determined not to be the optimal node at this point, the third node generates its own digital signature and aggregates it with the aggregated historical signature of the second node to obtain the aggregated historical signature of the third node. The node information of the third node and the aggregated historical signature are then added to the historical node information array as objects. The hop count is updated to 3. A link integrity hash "SHA256-HASH-OF-ROUTE-HISTORY-3" is generated and replaced with the content of the "rh" field in the link data. The complete link data is JSON-encoded, then base64-encoded and added to the request header. The API request is forwarded to the next node.

[0097] If the third node is determined to be the best node at this point, the third node will no longer forward API requests and will instead provide the API service.

[0098] If none of the nodes in the link data are the optimal node, and the current node determines that the current hop count is greater than or equal to the maximum allowed hop count, it will stop forwarding, provide API services to the current node, and end the forwarding process.

[0099] Through the above embodiments, the method for generating call links provided in this application can implement a multi-layer security protection mechanism for link data, including current node signature, aggregated historical signature, and link integrity hash, to ensure that link data is not tampered with during forwarding by different provider nodes; it can detect call links in real time to prevent loops; the information of previously called historical nodes is transparent to the current node, enabling link auditing; the detection and auditing of links are completed by the node receiving the request, making it easy to deploy in a distributed environment.

[0100] Figure 2 This is a block diagram illustrating a call chain generation apparatus according to an exemplary embodiment. (Reference) Figure 2 The call link generation device is applied to the node and includes: a request receiving module 201, a parsing module 202, a verification module 203, a detection module 204, a node information writing module 205, and a forwarding module 206.

[0101] The request receiving module 201 is configured to receive API requests.

[0102] The parsing module 202 is configured to parse the header information of the API request and determine whether link data exists. The link data includes the number of hops, the maximum allowed number of hops, and an array of historical node information.

[0103] The verification module 203 is configured to verify the validity of the historical node information array if link data exists.

[0104] The detection module 204 is configured to perform loop detection if the historical node information array is valid.

[0105] The node information writing module 205 is configured to add the node information of the current node to the historical node information array if no loop exists.

[0106] The forwarding module 206 is configured to update the hop count and forward API requests to the next node when the hop count is less than the maximum allowed hop count.

[0107] In one exemplary embodiment, the parsing module 202 is further configured to create link data if no link data exists.

[0108] The node information writing module 205 is also configured to generate a unique link identifier, set a maximum allowed number of hops, and add the node information of the current node to the node information array.

[0109] In one exemplary embodiment, the node information writing module 205 is further configured to: When the node is the first node, generate the signature of the current node; Add the node information and signature of the current node to the historical node information array; If the node is not the first node, generate the signature of the current node; Obtain the signatures of historical nodes, and generate an aggregated historical signature based on the signatures of the current node and the historical nodes; Add the current node's node information and aggregated historical signatures to the historical node information array.

[0110] In one exemplary embodiment, the forwarding module 206 is further configured to: generate a link integrity hash and add it to the link data.

[0111] In one exemplary embodiment, the detection module 204 is further configured to: Used to traverse the information of all nodes in the historical node information array. For example, if there are two unique identifiers for a certain node, it is determined that there is a loop in the link; or, if the unique identifier of the current node's provider exists in the historical node information array, it is determined that there is a loop in the link.

[0112] Figure 3 This is a block diagram illustrating a computer device 300 for generating call chains according to an exemplary embodiment. For example, the computer device 300 may be provided as a server. (Refer to...) Figure 3 The computer device 300 includes a processor 301, the number of which can be set to one or more as needed. The computer device 300 also includes a memory 302 for storing instructions executable by the processor 301, such as application programs. The number of memories can be set to one or more as needed. The stored application programs can be one or more. The processor 301 is configured to execute instructions to perform the aforementioned call chain generation method.

[0113] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus (devices), or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code. Computer storage media include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data), including but not limited to RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and can include any information delivery medium.

[0114] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0115] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0116] In this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that an article or device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such an article or device. Without further limitation, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the article or device that includes said element.

[0117] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0118] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if these modifications and variations fall within the scope of the claims of this application and their equivalents, the intent of this application also includes these modifications and variations.

Claims

1. A method for generating a call chain, characterized in that, Applied to nodes, including: Receive API requests; Parse the header information of the API request to determine whether there is link data, which includes the number of hops, the maximum allowed number of hops, and an array of historical node information; If link data exists, the validity of the historical node information array is verified; If the historical node information array is valid, perform loop detection; If no loop exists, add the current node's node information to the historical node information array; Update the hop count. If the hop count is less than the maximum allowed hop count, forward the API request to the next node.

2. The method for generating a call chain as described in claim 1, characterized in that, Also includes: If the link data does not exist, create the link data. Generate a unique link identifier, set the maximum allowed number of hops, and add the current node's node information to the historical node information array.

3. The method for generating call chains as described in claim 2, characterized in that, The node information includes: a unique provider identifier, a timestamp of the received request, and a geolocation code; The node information of multiple nodes in the historical node information array is stored in chronological order.

4. The method for generating call chains as described in claim 3, characterized in that, Adding the current node's node information to the historical node information array includes: When the node is the first node, generate the signature of the current node; Add the node information and signature of the current node to the historical node information array; If the node is not the first node, generate the signature of the current node; Obtain the signatures of historical nodes, and generate an aggregated historical signature based on the signatures of the current node and the historical nodes; Add the node information of the current node and the aggregated historical signature to the historical node information array.

5. The method for generating call chains as described in claim 3, characterized in that, The update hop count is followed by: generating a link integrity hash and adding it to the link data.

6. The method for generating a call chain as described in claim 3, characterized in that, The loop detection includes: Iterate through the information of all nodes in the historical node information array. If a node has two unique provider identifiers, it is determined that there is a loop in the link; or, if the unique provider identifier of the current node exists in the historical node information array, it is determined that there is a loop in the link.

7. A device for generating a call chain, characterized in that, Applied to nodes, including: The request receiving module is used to receive API requests; The parsing module is used to parse the header information of the API request and determine whether there is link data. The link data includes the number of hops, the maximum allowed number of hops, and an array of historical node information. The verification module is used to verify the validity of the historical node information array if link data exists. The detection module is used to perform loop detection if the historical node information array is valid. The node information writing module is used to add the node information of the current node to the historical node information array if there is no loop. The forwarding module is used to update the hop count. When the hop count is less than the maximum allowed hop count, the API request is forwarded to the next node.

8. The call chain generation apparatus as described in claim 7, characterized in that, The parsing module is also used to: create link data if no link data exists; The node information writing module is also used to: generate a unique link identifier, set the maximum allowed number of hops, and add the node information of the current node to the historical node information array.

9. The call chain generation apparatus as described in claim 8, characterized in that, The node information writing module is also used for: When the node is the first node, generate the signature of the current node; Add the node information and signature of the current node to the historical node information array; If the node is not the first node, generate the signature of the current node; Obtain the signatures of historical nodes, and generate an aggregated historical signature based on the signatures of the current node and the historical nodes; Add the node information of the current node and the aggregated historical signature to the historical node information array.

10. The call chain generation apparatus as described in claim 8, characterized in that, The forwarding module is also used for: Generate a link integrity hash and add it to the link data.

11. The call chain generation apparatus as described in claim 8, characterized in that, The detection module is also used for: Iterate through the information of all nodes in the historical node information array. If a node has two unique provider identifiers, it is determined that there is a loop in the link; or, if the unique provider identifier of the current node exists in the historical node information array, it is determined that there is a loop in the link.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed, it implements the steps of the method as described in any one of claims 1-6.

13. A computer device comprising a processor, a memory, and a computer program stored in the memory, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1-6.

Images