A request processing method and device

By introducing a marking value mechanism between the server and the client, the class name, method name and parameter type in the method call list are cached and marked, and a new transmission protocol is generated, which solves the small throughput problem caused by the fixed network transmission protocol in the existing technology, and achieves more efficient request processing.

CN113722126BActive Publication Date: 2025-04-15BEIJING WODONG TIANJUN INFORMATION TECH CO LTD +1
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202111060457.8
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2021-09-09
Publication Date
2025-04-15
Estimated Expiration
2041-09-09

AI Technical Summary

Technical Problem

The existing Provider and Consumer ends are fixed on the network transmission protocol, resulting in a huge number of bytes transmitted, affecting the throughput of the Provider end to process requests.

Method used

By introducing a marking value mechanism between the server and the client, the class name, method name and parameter type in the method call list are pre-cachedated and marked, to generate a new transmission protocol and reduce the number of bytes transmitted.

Benefits of technology

It significantly reduces the number of bytes of the transmission protocol, improves the throughput of the Provider side to process requests, and simplifies communication between the Consumer side and the Provider side.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113722126B_ABST
    Figure CN113722126B_ABST
Patent Text Reader

Abstract

The present invention discloses a request processing method and device, and relates to the field of computer technology. A specific implementation of the method includes: a server receives a method call request transmitted by a client, parses the transmission protocol in the method call request, and obtains a marking value under a preset field; locally queries a method corresponding to the marking value, calls the method, obtains a call result, and returns it to the client. Compared with the existing general transmission protocol, this implementation scheme omits the class name, method name, and parameter type of the call, saves the transmission volume, and improves the throughput of the request that the server can process.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a request processing method and device. Background Art

[0002] At present, each enterprise has set up its own RPC (Remote Procedure Call) service framework for internal use. However, due to different setting standards, the overall effect and throughput are also different. The only similarity is that when the Consumer calls the method on the Provider, it encapsulates the request ID (RequestID), the called class name (InvokeClass), the method name (InvokeMethod), the parameter type (ParameterTypes) and the parameter value array (ParameterValues) as the request context, and then transmits it to the Provider for parsing and calling. After that, the Provider returns the call result to the Consumer. At this point, a complete request is processed.

[0003] In the process of implementing the present invention, the inventors found that the prior art has at least the following problems: At present, enterprises mainly focus on how to achieve better plug-in for RPC services and how to make RPC service calls more convenient and easy to use, but stick to the old ways in terms of network transmission protocols. See Table 1 for the general transmission protocol setting form. The overall call is in byte mode. The Consumer encapsulates the transmission protocol into a request context according to the specific content. The overall number of bytes transmitted is 792 bytes. It can be seen that the overall message body is huge, which affects the throughput of the Provider end processing messages.

[0004] Table 1

[0005] Summary of the invention

[0006] In view of this, an embodiment of the present invention provides a request processing method and device, which can at least solve the problem that the existing Provider and Consumer have fixed network transmission protocols, the number of transmitted bytes is huge, and the request throughput that the Provider can process is small.

[0007] To achieve the above-mentioned purpose, according to one aspect of an embodiment of the present invention, a request processing method applied to a server is provided, including: the server receives a method call request transmitted by a client, parses the transmission protocol in the method call request, and obtains a marking value under a preset field; locally queries a method corresponding to the marking value, calls the method, obtains a call result and returns it to the client.

[0008] Optionally, the marking value corresponds to the class name, method name and parameter type involved in the method; before the server receives the method call request transmitted by the client, it also includes: receiving a synchronization request for a method call list transmitted by the client, caching the class name, method name and parameter type involved in each method in the method call list locally and marking them; using a preset string as the protocol header, the method call list and the marking value for each method as the protocol body, encapsulating a new transmission protocol and returning it to the client.

[0009] Optionally, before receiving the synchronization request for the method call list transmitted by the client, it also includes: during the startup process, establishing a binding relationship with the port number preset by the client; and publishing the service to the registration center and marking it as offline, so that after monitoring the connection request transmitted by the client, the service is marked as online; wherein a service includes one or more methods.

[0010] Optionally, it also includes: in response to an operation to change the marking value of one or more methods, replacing the locally cached marking value information with the changed current marking value information; using a preset string as a protocol header and the current marking value information as a protocol body, encapsulating a new transmission protocol and transmitting it to the client to update the method marking value information.

[0011] Optionally, after the operation of changing the marking value of one or more methods in response, it also includes: determining whether a hot deployment strategy for synchronizing the method call list is set; if not set, then after restarting the server, verifying whether the current marking value information of the one or more methods is consistent with the locally cached marking value information; or if set, then after executing the hot deployment strategy, scanning the current marking value information of each method for comparison with the locally cached method marking value list.

[0012] Optionally, it also includes: in the process of processing the client request, if it is monitored that the connection with the client is temporarily disconnected, the heartbeat packets reported by the client are continuously counted; if the count exceeds a preset value and no heartbeat packet reported by the client is received, it is determined that the client is in an offline state, and the connection relationship with the client is terminated; after the network returns to normal and the connection request transmitted by the client is received, the connection relationship with the client is re-established, and then after receiving the heartbeat packet transmitted by the client, the connection relationship is marked as a valid connection to perform synchronization operations on the method call list of the client.

[0013] To achieve the above-mentioned purpose, according to one aspect of an embodiment of the present invention, there is provided a request processing method applied to a client, comprising: the client receives a user's call request for a method, and locally queries a marking value for the method; uses the marking value as the byte content of a preset field to encapsulate a transmission protocol; encapsulates the transmission protocol into a new call request and transmits it to a server, then receives a call result returned by the server, and returns the call result to the user.

[0014] Optionally, the marking value corresponds to the class name, method name and parameter type involved in the method; before the client receives the user's call request for the method, it also includes: transmitting a synchronization request for the method call list to the server, and receiving the result returned by the server; if the protocol header of the transmission protocol in the result is a preset string, it is determined that the result includes the method call list and the marking value for each method; the method call list and the marking value for each method are cached locally.

[0015] Optionally, the transmission of the synchronization request for the method call list to the server includes: searching for the server with the smallest current load in the registration center through load balancing; transmitting a connection request to the server to establish a connection relationship with the server, and then transmitting the synchronization request for the method call list to the server through the connection relationship.

[0016] Optionally, it also includes: when the method marking value at the server is changed, receiving and parsing the transmission protocol transmitted by the server to obtain a protocol header and a protocol body; if the protocol header is a preset string, updating the locally cached method marking value information based on the method marking value information in the protocol body.

[0017] Optionally, it also includes: if a disconnection and reconnection situation occurs, determining the server of the last connection, and re-establishing the connection relationship with the server based on the connection information between the server and the server; encapsulating the heartbeat packet and transmitting it to the server, and at the same time transmitting a synchronization request for the method call list to the server, and then receiving the result returned by the server; if the protocol header of the transmission protocol in the result is a preset string, determining that the result includes the method call list and the marking value for each method; based on the method call list and the marking value for each method, updating the local cache.

[0018] To achieve the above-mentioned purpose, according to another aspect of an embodiment of the present invention, there is provided a request processing device applied to a server, including: a parsing module, which is used for the server to receive a method call request transmitted by a client, parse the transmission protocol in the method call request, and obtain a marking value under a preset field; a calling module, which is used to locally query the method corresponding to the marking value, call the method, obtain the calling result and return it to the client.

[0019] Optionally, the marking value corresponds to the class name, method name and parameter type involved in the method; and also includes a synchronization module, which is used to: receive a synchronization request for a method call list transmitted by a client, cache the class name, method name and parameter type involved in each method in the method call list locally and mark them; use a preset string as the protocol header, the method call list and the marking value for each method as the protocol body, encapsulate a new transmission protocol and return it to the client.

[0020] Optionally, it also includes a registration service module, which is used to: establish a binding relationship with the port number preset by the client during the startup process; and publish the service to the registration center and mark it as offline, so that after monitoring the connection request transmitted by the client, the service will be marked as online; wherein a service includes one or more methods.

[0021] Optionally, it also includes a marking value update module, which is used to: in response to the marking value change operation of one or more methods, replace the locally cached marking value information with the changed current marking value information; use a preset string as the protocol header and the current marking value information as the protocol body, encapsulate a new transmission protocol and transmit it to the client to update the method marking value information.

[0022] Optionally, the marking value update module is also used to: determine whether a hot deployment strategy for synchronizing the method call list is set; if not, then after restarting the server, verify whether the current marking value information of the one or more methods is consistent with the locally cached marking value information; or if set, then after executing the hot deployment strategy, scan the current marking value information of each method for comparison with the locally cached method marking value list.

[0023] Optionally, it also includes a disconnection reconnection module, which is used to: in the process of processing client requests, if it is monitored that the connection with the client is temporarily disconnected, the heartbeat packets reported by the client are continuously counted; if the count exceeds a preset value and no heartbeat packet reported by the client is received, it is determined that the client is in a disconnected state, and the connection relationship with the client is terminated; after the network returns to normal and the connection request transmitted by the client is received, the connection relationship with the client is re-established, and then after receiving the heartbeat packet transmitted by the client, the connection relationship is marked as a valid connection, so as to synchronize the method call list of the client.

[0024] To achieve the above-mentioned purpose, according to another aspect of an embodiment of the present invention, there is provided a device for processing client requests, including: a receiving module, used for the client to receive a user's call request for a method, and locally query the marking value of the method; an encapsulation module, used for using the marking value as the byte content of a preset field to encapsulate a transmission protocol; a transmission module, used for encapsulating the transmission protocol into a new call request and transmitting it to a server, then receiving the call result returned by the server, and returning the call result to the user.

[0025] Optionally, the marking value corresponds to the class name, method name and parameter type involved in the method; and also includes a synchronization module, which is used to: transmit a synchronization request for the method call list to the server, and receive the result returned by the server; if the protocol header of the transmission protocol in the result is a preset string, then determine that the result includes the method call list and the marking value for each method; cache the method call list and the marking value for each method locally.

[0026] Optionally, the synchronization module is used to: find the server with the smallest current load in the registration center through load balancing; transmit a connection request to the server to establish a connection relationship with the server, and then transmit a synchronization request for the method call list to the server through the connection relationship.

[0027] Optionally, it also includes a marking value update module, which is used to: when the method marking value at the server is changed, receive and parse the transmission protocol transmitted by the server to obtain the protocol header and protocol body; if the protocol header is a preset string, then based on the method marking value information in the protocol body, update the locally cached method marking value information.

[0028] Optionally, it also includes a disconnection and reconnection module, which is used to: if a disconnection and reconnection situation occurs, determine the server of the last connection, and re-establish the connection relationship with the server based on the connection information between the server; encapsulate the heartbeat packet and transmit it to the server, and at the same time transmit a synchronization request for the method call list to the server, and then receive the result returned by the server; if the protocol header of the transmission protocol in the result is a preset string, determine that the result includes the method call list and the marking value for each method; based on the method call list and the marking value for each method, update the local cache.

[0029] To achieve the above objective, according to another aspect of an embodiment of the present invention, a request processing electronic device is provided.

[0030] The electronic device of an embodiment of the present invention includes: one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, the one or more processors implement any of the request processing methods described above.

[0031] To achieve the above objective, according to another aspect of an embodiment of the present invention, a computer-readable medium is provided, on which a computer program is stored, and when the program is executed by a processor, any of the above request processing methods is implemented.

[0032] According to the solution provided by the present invention, an embodiment of the above invention has the following advantages or beneficial effects: for the Provider and Consumer ends, since the called class name, method name, and parameter type are all known, these two parts can be completely coordinated in advance, that is, by removing the called class name, method name, and parameter type, the number of bytes of the transmission protocol can be greatly simplified, and the transmission volume can be reduced, thereby improving the request throughput.

[0033] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with the specific implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0035] Figure 1 This is a main flow chart of a request processing method applied to a server according to an embodiment of the present invention;

[0036] Figure 2 is a flowchart of an optional request processing method applied to a server according to an embodiment of the present invention;

[0037] Figure 3 This is a main flow chart of a request processing method applied to a client according to an embodiment of the present invention;

[0038] Figure 4 is a flow chart of an optional request processing method applied to a client according to an embodiment of the present invention;

[0039] Figure 5 is a schematic diagram of a specific request processing method flow interaction according to an embodiment of the present invention;

[0040] Figure 6 is a flowchart of an optional request processing method according to an embodiment of the present invention;

[0041] Figure 7 is a flowchart of another optional request processing method according to an embodiment of the present invention;

[0042] Figure 8 is a schematic diagram of main modules of a request processing device applied to a server according to an embodiment of the present invention;

[0043] Fig. 9 is a schematic diagram of main modules of a request processing device applied to a client according to an embodiment of the present invention;

[0044] Fig.10 is an exemplary system architecture diagram to which embodiments of the present invention may be applied;

[0045] Fig.11 It is a schematic diagram of the structure of a computer system of a mobile device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0046] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0047] Call method Com.xx.coupon.service.getCouponInfo(List <int>skuids), and its transmission protocol is designed as shown in Table 1 (irrelevant field information has been omitted). After the transmission protocol is encapsulated as a request context according to the specific content, the total number of bytes transmitted is: 4+4+8+64+64+128+512+8=792 bytes. It can be seen that the overall message body is huge.

[0048] Since the called class name, method name, and parameter type are known to both the Provider and Consumer, this part can be coordinated in advance. By removing the called class name, method name, and parameter type, the number of bytes that can be reduced is about 200 bytes, and the overall protocol body will be greatly streamlined, thereby improving the request throughput processed by the Provider.

[0049] Explanation of technical terms in this solution:

[0050] RPC: Remote Procedure Call, remote procedure call, the process of mutual calling between remote machines.

[0051] Transmission protocol: the business logic for interaction between different ends when they call each other.

[0052] Provider side: service provider, server side.

[0053] Consumer side: service caller, client.

[0054] Registry: The place where services are centrally registered.

[0055] See also Figure 1 , which shows a main flow chart of a request processing method applied to a server provided by an embodiment of the present invention, including the following steps:

[0056] S101: The server receives a method call request transmitted by a client, parses the transmission protocol in the method call request, and obtains a marking value under a preset field;

[0057] S102: locally querying a method corresponding to the marking value, calling the method, obtaining a calling result and returning it to the client.

[0058] In the above implementation, for step S101, before calling the method normally, the Consumer will pre-transmit a synchronization request for the method call list to the Provider, and then store the method call list and the marking value of each method returned by the Provider locally, and then communicate and interact on this basis. For details, see the subsequent Figure 2 and Figure 4 The description shown is not repeated here.

[0059] After receiving the method call request transmitted by the Consumer, the Provider will parse the transmission protocol in the request (the transmission protocol is encapsulated as the request context according to the specific content) to query the tag value under the preset field, such as the tag value ACIL under the invokeflag field, which corresponds to the addCouponInfo method.

[0060] Table 2

[0061]

[0062] It should be noted that, compared with Table 1, the preset field invoke flag here corresponds to the class name (Class name), method name (Method Name) and parameter type (ParameterTypes) in Table 1, and the marking value corresponds to the whole of these three.

[0063] For step S102, the Provider side finds the method corresponding to the marked value from the local cache, puts in the parameter content for calling, such as calling the method hello(String name) where String is the parameter type and name is the parameter content, and then returns the calling result to the Consumer side.

[0064] Compared with the existing general transmission protocol, the method provided in the above embodiment omits the calling class name, method name and parameter type, saves the transmission volume, and improves the throughput of requests that can be processed by the server.

[0065] See also Figure 2 , shows a schematic flow chart of an optional request processing method applied to a server according to an embodiment of the present invention, comprising the following steps:

[0066] S201: During the startup process, the server establishes a binding relationship with the port number preset by the client;

[0067] S202: publishing the service to the registration center and marking it as offline, so that after monitoring the connection request transmitted by the client, the service is marked as online; wherein a service includes one or more methods;

[0068] S203: receiving a synchronization request for a method call list transmitted by a client, caching the class name, method name and parameter type involved in each method in the method call list locally and marking them;

[0069] S204: Using the preset character string as the protocol header, the method call list and the marking value of each method as the protocol body, encapsulate a new transmission protocol and return it to the client.

[0070] In the above implementation, for steps S201 and S202, the Provider starts and binds the port number specified by the Consumer, which is set by default by the user at the Consumer, such as 13295. The services that need to be exposed are then published to the registration center and marked as offline, such as unified login authentication services, risk control services, etc. In the process of microservices, a large number of such services will be split out. The Provider then starts to monitor whether the Consumer transmits a connection request. If it is detected, the service exposed to the registration center is marked as online; a service includes one or more methods, which together constitute a method call list.

[0071] It should be noted that the synchronized method call list and method marking value list have not yet been implemented (see Figure 5 As shown in the figure, if the service is not marked as offline, the Provider will receive external request traffic, causing other problems. Therefore, the service is first marked as offline, and after starting to process the connection request transmitted by the Consumer, the service is marked as online, and then receives external request traffic.

[0072] For step S203, the Provider receives the synchronization request for the method call list transmitted by the Consumer (for example, the protocol starts with 0x009), first caches the method call list exposed to the registration center locally on the Provider, and then marks the class name, method name and parameter type involved in the service. Alternatively, the method call list is cached and marked first, and then the synchronization request for the method call list transmitted by the Consumer is received. The execution order is not limited in this solution and is specifically set by the staff.

[0073] For example, the method call list at the Provider end includes:

[0074] Com.xx.coupon.service.getCouponInfo(List <int>skuids); (Method 1)

[0075] Com.xx.coupon.service.addCouponInfo(List <int>skuids); (Method 2)

[0076] The two methods are cached locally, and the class name, method name and parameter type involved in method 1 are marked as GCIL, and the class name, method name and parameter type involved in method 2 are marked as ACIL.

[0077] For step S204, a new transmission protocol is assembled and returned to the Consumer, including a preset protocol header (for example, the encapsulated protocol starts with 0x010) and a protocol body, which includes a method call list and a marking value for each method. Then, the Consumer continues to listen for requests.

[0078] Table 3 Modified parts of the transmission protocol

[0079]

[0080] Table 3 Transmission protocol after modification (byte content is not included here)

[0081]

[0082] For example, the Provider has a service com.xx.HelloService, which includes a call method hello(String name). The method is cached locally on the Provider in the aforementioned way and tagged, such as HSN->com.xx.HelloService.hello(String name). The HSN here is custom and only needs to be distinguished from the tag values ​​of other methods. When the Consumer transmits a synchronization request for the method call list to the Provider, the Provider will encapsulate "HSN->com.xx.HelloService.hello(String name)" into the transmission protocol and then return it to the Consumer.

[0083] The method provided in the above embodiment is the first handshake and connection establishment part between the server and the client. After the two establish a connection relationship, the method call list and the synchronization of the method marking value are started, providing a basis for reducing the transmission protocol volume for subsequent method calls.

[0084] See also Figure 3 , shows a schematic flow chart of a request processing method applied to a client according to an embodiment of the present invention, comprising the following steps:

[0085] S301: The client receives a user's request to call a method, and locally queries a marking value for the method;

[0086] S302: Using the marking value as the byte content of the preset field to encapsulate and obtain a transmission protocol;

[0087] S303: Encapsulate the transmission protocol into a new call request and transmit it to the server, then receive the call result returned by the server, and return the call result to the user.

[0088] In the above implementation, for steps S301 to S303, the Consumer receives a method call request from a user and starts to call the method. Specifically, it searches the local cache for the tag value corresponding to the method. For example, when a user requests to call the addCouponInfo method, the Consumer first searches the local cache for the corresponding tag ACIL and then encapsulates the protocol according to the protocol format (example encapsulation, mainly based on actual application):

[0089] Table 4

[0090]

[0091] When encapsulating the transmission protocol, first replace the class name (Class name), method name (MethodName) and parameter type (ParameterTypes) in the called method with the preset field invoke flag, and set the marking value ACIL for it, as shown in Table 4. The new transmission protocol is encapsulated, and a new call request is obtained to be transmitted to the Provider end, and then the call result returned by the Provider end is received and returned to the user.

[0092] The method provided in the above embodiment first encapsulates the method call request according to the protocol format at the client. At this time, there is no need to encapsulate the class name, method name, parameter type, etc. into the protocol one by one. It is only necessary to add a marking value to the preset field in the transmission protocol. Compared with the existing general transmission protocol, the transmission volume is saved.

[0093] See also Figure 4 , shows a schematic flow chart of an optional request processing method applied to a client according to an embodiment of the present invention, comprising the following steps:

[0094] S401: The client searches for the server with the smallest current load in the registration center through load balancing.

[0095] S402: Transmitting a connection request to the server to establish a connection relationship with the server;

[0096] S403: transmitting the synchronization request for the method call list to the server through the connection relationship, and then receiving the result returned by the server;

[0097] S404: If the protocol header of the transmission protocol in the result is a preset character string, determine that the result includes a method call list and a marking value for each method, and cache the method call list and the marking value for each method locally.

[0098] In the above implementation, for steps S401 to S403, for the Consumer, it will first go to the registration center to find a Provider with the smallest current load from multiple Providers through load balancing, and then directly connect to it. Specifically, it will transmit a connection request to the Provider to establish a connection relationship with the Provider. Then, through the connection relationship, it will transmit a synchronization request for the method call list to the Provider, and listen to the return of the Provider. If there is no return, it will continue to listen.

[0099] For step S404, after receiving the result returned by the Provider, the Consumer parses the transmission protocol. If the transmission protocol starts with a preset string (such as 0x010), it means that the received result includes a method call list to be synchronized and a marking value for each method. The method call list and the marking value for each method are cached locally on the Consumer.

[0100] For example, there is a service com.xx.HelloService on the Provider side, which contains a calling method hello(String name). This method is marked in the local cache on the Provider side through the aforementioned method, such as HSN->com.xx.HelloService.hello(String name). The HSN here is custom and can be distinguished from the marking values ​​of other methods.

[0101] When the Consumer transmits a synchronization request for the method call list to the Provider, the Provider will wrap "HSN->com.xx.HelloService.hello(String name)" into the transmission protocol and transmit it to the Consumer. After receiving the transmission protocol, the Consumer will also write HSN->com.xx.HelloService.hello(String name) in the local cache. Subsequently, the Consumer only needs to transmit the HSN tag to the Provider. After detecting the HSN, the Provider can quickly locate the corresponding call method.

[0102] In the method provided in the above embodiment, the client receives the method call list and the marking value of each method from the server, caches the method call list locally, and marks it with the same mark as the server. Subsequently, the Provider and Consumer have a copy of the method call list that they need to interact with.

[0103] See also Figure 5 , shows a specific request processing method flow interaction diagram according to an embodiment of the present invention, including the following steps:

[0104] 1. During the startup process, the Provider establishes a binding relationship with the preset port number of the Consumer;

[0105] 2. The Provider publishes the service to the registration center and marks it as offline; a service includes one or more methods.

[0106] 3. The Consumer side searches for the Provider side with the smallest current load through load balancing in the registration center, and transmits a connection request to the Provider side to establish a connection relationship with the Provider side.

[0107] 4. After monitoring the connection request transmitted by the Consumer, the Provider marks the service as online;

[0108] 5. The Consumer transmits the synchronization request for the method call list to the Provider through the connection relationship;

[0109] 6. The Provider receives the synchronization request for the method call list transmitted by the Consumer, caches the class name, method name and parameter type involved in each method in the method call list locally and marks them;

[0110] 7. The Provider uses the preset string as the protocol header, the method call list and the marking value of each method as the protocol body, encapsulates a new transmission protocol and returns it to the Consumer;

[0111] 8. The Consumer receives the result returned by the Provider. If the protocol header of the transmission protocol in the result is a preset string, the result is determined to include a method call list and a marking value for each method and cached;

[0112] 9. The Consumer receives the method call request from the user, queries the marking value of the method locally, and uses the marking value as the byte content of the preset field;

[0113] 10. The Consumer encapsulates the transmission protocol, encapsulates the transmission protocol into a new call request and transmits it to the Provider;

[0114] 11. The Provider receives the method call request transmitted by the Consumer, parses the transmission protocol in the method call request, obtains the tag value under the preset field, locally queries the method corresponding to the tag value, calls the method, obtains the call result and returns it to the Consumer;

[0115] 12. The Consumer receives the call result returned by the Provider and returns the call result to the user.

[0116] See also Figure 6 , shows a schematic flow chart of an optional request processing method according to an embodiment of the present invention, comprising the following steps:

[0117] S601: In response to the operation of changing the marking value of one or more methods, the server determines whether a hot deployment strategy for method call list synchronization is set;

[0118] S602: If not set, after restarting the server, verify whether the current marking value information of the one or more methods is consistent with the marking value information cached locally;

[0119] S603: If set, after executing the hot deployment strategy, scan the current tag value information of each method to compare with the locally cached method tag value list;

[0120] S604: When the comparison result is inconsistent, the locally cached marking value information is replaced with the changed current marking value information;

[0121] S605: Using a preset character string as a protocol header and the current marking value information as a protocol body, encapsulate a new transmission protocol and transmit it to the client to update the method marking value information;

[0122] S606: The client receives and parses the transmission protocol transmitted by the server to obtain a protocol header and a protocol body;

[0123] S607: If the protocol header is a preset character string, based on the current marking value information in the protocol body, the locally cached method marking value information is updated.

[0124] In the above implementation, for step S601, the change of the method tag value is usually related to the business change of the business party. For example, the service com.xx.HelloService has a hello(String name) method. With the upgrade of the business or the increase of business needs, if the user address needs to be carried, the staff finds that the hello(String name) method can no longer meet the business needs. At this time, it will be upgraded, such as upgraded to hello(String name, String userAddress).

[0125] To update the method tag value on the provider side, you usually need to restart the server to publish the new method tag value. However, some providers have a hot deployment strategy, which allows them to publish new method tag values ​​without restarting. The hot deployment strategy here can be regarded as a synchronization mechanism for the method call list.

[0126] For steps S602 to S603, if the Provider does not set a hot deployment strategy, that is, for the restarted Provider, it will verify whether the method tag value has changed after restarting by pre-storing data in the database or other means, such as comparing the versions. For the Provider with a hot deployment strategy, after the hot deployment strategy is executed, the local method tag value worker will scan the tag value of each method and then compare it with the locally cached method tag value list.

[0127] When the Provider restarts publishing, regardless of whether the method tag value is updated, it will include a special protocol header, such as 0x010, in the protocol when establishing a connection with the Consumer, and the protocol body includes the updated method tag value information, method call list, and method tag value. When the Consumer receives this response protocol, it will update the local cache.

[0128] For steps S604 to S605, once the method tag value is updated, the Provider will verify the local method tag value regardless of whether it is restarted. If there is no change, no processing will be done, but if there is a change, the local cached tag value information will be replaced with the current tag value information. Assemble the transmission protocol, use the preset string (such as 0x010) as the protocol header, and the current new method tag value list information as the protocol body, and transmit it to the Consumer connected to the Provider for updating.

[0129] For steps S606 to S607, after the Consumer receives the transmission protocol transmitted by the Provider, it parses the protocol header of the transmission protocol. If the protocol header is 0x010, it means that this is an update operation. Based on the current method marking value list information in the protocol body, the local method marking value information is updated.

[0130] The method provided in the above embodiment may update the interface method tag value from time to time due to business reasons when designing the interface, and respond to such processing updates through a set of predetermined protocol headers to ensure timely synchronization of the method tag values ​​at the Consumer and Provider ends.

[0131] See also Figure 7 , shows a schematic flow chart of another optional request processing method according to an embodiment of the present invention, comprising the following steps:

[0132] S701: When the server is processing a request from a client, if it detects that the connection with the client is disconnected, the server continuously counts the heartbeat packets reported by the client.

[0133] S702: If the count exceeds a preset value and no heartbeat packet reported by the client is received, it is determined that the client is offline, and the connection relationship with the client is removed;

[0134] S703: after the network returns to normal and a connection request transmitted by the client is received, the connection relationship with the client is reestablished, and after a heartbeat packet transmitted by the client is received, the connection relationship is marked as a valid connection, so as to perform a synchronization operation on the method call list of the client;

[0135] S704: If the client is disconnected and reconnected, the client determines the server that was last connected, and re-establishes the connection relationship with the server based on the connection information between the client and the server;

[0136] S705: Encapsulate the heartbeat packet and transmit it to the server, and at the same time transmit a synchronization request for the method call list to the server, and then receive the result returned by the server;

[0137] S706: If the protocol header of the transmission protocol in the result is a preset character string, determine that the result includes a method call list and a marking value for each method;

[0138] S707: Based on the method call list and the marking value of each method, update the local cache.

[0139] In the above implementation, for steps S701 to S707, during the network interaction, the network may not always be in a stable state, and the network may be disconnected for some reason. At this time, the Provider generally detects the validity of the connection by receiving the heartbeat packet from the Consumer. If the heartbeat packet reported by the Consumer is not received for three consecutive times (the value is only an example and is actually adjustable), the Consumer is considered to be offline, and the connection relationship of this Consumer will be kicked off.

[0140] However, after the network returns to normal, the Consumer usually has a disconnection reconnection mechanism to ensure availability. At this time, the Consumer will determine which Provider it was connected to last time and obtain the connection information with the Provider, then initiate a reconnection operation to reestablish the connection relationship. If the reconnection fails, it will retry until the reconnection succeeds.

[0141] After the connection is successful, the Consumer will first encapsulate the heartbeat packet and transmit it to the Provider, so that the Provider can mark the above connection information as a valid connection. At the same time, it transmits a synchronization request for the method call list to the Provider. The protocol header of the transmission protocol in the synchronization request is 0x009. When the Provider receives the protocol header of 0x009, it believes that the connection between the two ends was disconnected due to some factors before, and needs to resynchronize the method call list. Therefore, it uses 0x010 as the protocol header, the method call list and the marking value of each method as the protocol body, encapsulates a new transmission protocol and returns it to the Consumer. After receiving this message, the Consumer will update the local method marking value list.

[0142] The method provided in the above embodiment proposes a solution for how to determine whether the connection is disconnected during the interaction between the server and the client and how to update after the connection is reconnected, so as to ensure that the information at the client is synchronized with the server.

[0143] The method provided in the embodiment of the present invention not only involves the improvement of the method marking value list during the interaction between the server and the client, but also involves the problem of how to transmit the method marking value list in the transmission protocol. For this situation:

[0144] 1. Modify the transmission protocol and add a preset string for update / synchronization. For example, 0x01 represents creation and 0x02 represents update / synchronization. If the transmission protocol is encapsulated as 0x02|HSN->com.xx.HelloService.hello(String name), it means that the method tag value needs to be updated;

[0145] 2. Also for the RPC service transmission part, when the server and client establish a connection relationship, the class name, method name, and parameter type involved in the method are cached through the preheating mechanism and marked with the same mark. In this way, both cache interactive copies with consistent calling methods. After that, the formal interactive transmission protocol only needs to be accompanied by the cache mark, which optimizes the overall volume of the transmission protocol by more than 30% (due to differences in transmission protocols, the actual volume optimization percentage is different), greatly improving the throughput efficiency of the RPC service framework;

[0146] 3. Due to the update of the transmission mechanism, the method marking value list update and disconnection reconnection mechanism have been redesigned to ensure timely synchronization of the method marking values ​​on the server and client.

[0147] See also Figure 8 , which shows a schematic diagram of main modules of a request processing device 800 applied to a server provided by an embodiment of the present invention, including:

[0148] Parsing module 801, used for receiving a method call request transmitted by a client at a server end, parsing a transmission protocol in the method call request, and obtaining a marking value under a preset field;

[0149] The calling module 802 is used to locally query the method corresponding to the marking value, call the method, obtain the calling result and return it to the client.

[0150] In the implementation device of the present invention, the marking value corresponds to the class name, method name and parameter type involved in the method;

[0151] Also includes synchronization modules for:

[0152] Receive a synchronization request for a method call list transmitted by a client, cache the class name, method name, and parameter type involved in each method in the method call list locally, and mark them;

[0153] A new transmission protocol is encapsulated with a preset string as the protocol header, the method call list and the marking value of each method as the protocol body and returned to the client.

[0154] The implementation device of the present invention also includes a registration service module, which is used to:

[0155] During the startup process, a binding relationship is established with the port number preset by the client; and

[0156] The service is published to the registration center and marked as offline, so that after monitoring the connection request transmitted by the client, the service is marked as online; wherein a service includes one or more methods.

[0157] The implementation device of the present invention also includes a marking value updating module, which is used to:

[0158] In response to a marking value change operation on one or more methods, the locally cached marking value information is replaced with the changed current marking value information;

[0159] A preset character string is used as a protocol header and the current marking value information is used as a protocol body, and a new transmission protocol is encapsulated and transmitted to the client to update the method marking value information.

[0160] In the implementation device of the present invention, the marking value updating module is also used for:

[0161] Determine whether a hot deployment strategy for method call list synchronization is set;

[0162] If not set, after restarting the server, verify whether the current marking value information of the one or more methods is consistent with the marking value information cached locally; or

[0163] If set, after executing the hot deployment strategy, scan the current tag value information of each method to compare with the locally cached method tag value list.

[0164] The implementation device of the present invention also includes a disconnection reconnection module, which is used to:

[0165] In the process of processing the client request, if the connection with the client is detected to be disconnected, the heartbeat packets reported by the client are counted continuously;

[0166] If the count exceeds the preset value and no heartbeat packet reported by the client is received, the client is determined to be offline and the connection relationship with the client is removed;

[0167] After the network returns to normal and a connection request transmitted by the client is received, the connection relationship with the client is reestablished, and then after receiving a heartbeat packet transmitted by the client, the connection relationship is marked as a valid connection to perform a synchronization operation on the method call list for the client.

[0168] See also Fig. 9 , which shows a schematic diagram of main modules of a request processing device 900 applied to a client provided by an embodiment of the present invention, including:

[0169] Receiving module 901, used for the client to receive a user's call request for a method and query the marking value of the method locally;

[0170] An encapsulation module 902, configured to use the marking value as the byte content of a preset field to encapsulate and obtain a transmission protocol;

[0171] The transmission module 903 is used to encapsulate the transmission protocol into a new call request and transmit it to the server, then receive the call result returned by the server, and return the call result to the user.

[0172] In the implementation device of the present invention, the marking value corresponds to the class name, method name and parameter type involved in the method;

[0173] Also includes synchronization modules for:

[0174] Transmit a synchronous request for the method call list to the server and receive the result returned by the server;

[0175] If the protocol header of the transmission protocol in the result is a preset character string, determining that the result includes a method call list and a marking value for each method;

[0176] The method call list and the marking value of each method are cached locally.

[0177] In the implementation device of the present invention, the synchronization module is used to:

[0178] Use load balancing to find the server with the smallest current load in the registration center;

[0179] A connection request is transmitted to the server to establish a connection relationship with the server, and then a synchronization request for the method call list is transmitted to the server through the connection relationship.

[0180] The implementation device of the present invention also includes a marking value updating module, which is used to:

[0181] When the method tag value at the server is changed, the transmission protocol transmitted by the server is received and parsed to obtain the protocol header and the protocol body;

[0182] If the protocol header is a preset character string, the locally cached method marking value information is updated based on the method marking value information in the protocol body.

[0183] The implementation device of the present invention also includes a disconnection reconnection module, which is used to:

[0184] If a disconnection and reconnection occurs, the server that was last connected is determined, and the connection relationship with the server is reestablished based on the connection information between the server and the server;

[0185] Encapsulate the heartbeat packet and transmit it to the server, transmit the synchronization request for the method call list to the server, and then receive the result returned by the server;

[0186] If the protocol header of the transmission protocol in the result is a preset character string, determining that the result includes a method call list and a marking value for each method;

[0187] Based on the method call list and the marking value of each method, the local cache is updated.

[0188] In addition, the specific implementation content of the device described in the embodiment of the present invention has been described in detail in the method described above, so the repeated content will not be described again here.

[0189] Fig.10 An exemplary system architecture 1000 to which an embodiment of the present invention may be applied is shown, including terminal devices 1001 , 1002 , 1003 , a network 1004 and a server 1005 (only an example).

[0190] Terminal devices 1001, 1002, 1003 can be various electronic devices with display screens and supporting web browsing, and various communication client applications are installed. Users can use terminal devices 1001, 1002, 1003 to interact with server 1005 through network 1004 to receive or transmit messages, etc.

[0191] The network 1004 is used to provide a medium for communication links between the terminal devices 1001, 1002, 1003 and the server 1005. The network 1004 may include various connection types, such as wired, wireless communication links or optical fiber cables.

[0192] Server 1005 may be a server that provides various services, and is used to execute synchronization of method call lists, method marking, method call processing, method marking value synchronization, and client disconnection and reconnection operations.

[0193] It should be noted that the method provided in the embodiment of the present invention is generally executed by the server 1005 , and accordingly, the device is generally set in the server 1005 .

[0194] It should be understood that Fig.10 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0195] Reference below Fig.11 , which shows a schematic diagram of the structure of a computer system 1100 of a terminal device suitable for implementing an embodiment of the present invention. Fig.11 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0196] like Fig.11 As shown, the computer system 1100 includes a central processing unit (CPU) 1101, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1102 or a program loaded from a storage part 1108 into a random access memory (RAM) 1103. In the RAM 1103, various programs and data required for the operation of the system 1100 are also stored. The CPU 1101, the ROM 1102, and the RAM 1103 are connected to each other via a bus 1104. An input / output (I / O) interface 1105 is also connected to the bus 1104.

[0197] The following components are connected to the I / O interface 1105: an input section 1106 including a keyboard, a mouse, etc.; an output section 1107 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1108 including a hard disk, etc.; and a communication section 1109 including a network interface card such as a LAN card, a modem, etc. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to the I / O interface 1105 as needed. A removable medium 1111, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1110 as needed, so that a computer program read therefrom is installed into the storage section 1108 as needed.

[0198] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 1109, and / or installed from the removable medium 1111. When the computer program is executed by the central processing unit (CPU) 1101, the above-mentioned functions defined in the system of the present invention are executed.

[0199] It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which may transmit, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0200] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0201] The modules involved in the embodiments of the present invention may be implemented by software or hardware. The modules described may also be set in a processor, for example, it may be described as: a processor includes a parsing module and a calling module. The names of these modules do not constitute a limitation on the modules themselves in some cases, for example, the calling module may also be described as a "calling method module".

[0202] As another aspect, the present invention further provides a computer-readable medium, which may be included in the device described in the above embodiment; or may exist independently without being assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device includes:

[0203] The server receives the method call request transmitted by the client, parses the transmission protocol in the method call request, and obtains the marking value under the preset field;

[0204] A method corresponding to the marking value is queried locally, the method is called, and the calling result is obtained and returned to the client.

[0205] The technical solution according to the embodiment of the present invention not only involves the improvement of the method marking value list during the interaction between the server and the client, but also involves the problem of how to transmit the method marking value list in the transmission protocol. For this situation:

[0206] 1. Modify the transmission protocol and add a preset string for update / synchronization. For example, 0x01 represents creation and 0x02 represents update / synchronization. If the transmission protocol is encapsulated as 0x02|HSN->com.xx.HelloService.hello(String name), it means that the method tag value needs to be updated;

[0207] 2. Also for the RPC service transmission part, when the server and client establish a connection relationship, the class name, method name, and parameter type involved in the method are cached through the preheating mechanism and marked with the same mark. In this way, both cache interactive copies with consistent calling methods. After that, the formal interactive transmission protocol only needs to be accompanied by the cache mark, which optimizes the overall volume of the transmission protocol by more than 30% (due to differences in transmission protocols, the actual volume optimization percentage is different), greatly improving the throughput efficiency of the RPC service framework;

[0208] 3. Due to the update of the transmission mechanism, the method marking value list update and disconnection reconnection mechanism have been redesigned to ensure timely synchronization of the method marking values ​​on the server and client.

[0209] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.< / int> < / int> < / int>

Claims

1. A request processing method, characterized in that: include: The server receives a synchronization request for a method call list transmitted by the client, caches the class name, method name and parameter type involved in each method in the method call list locally and marks them; A new transmission protocol is encapsulated with a preset string as the protocol header, the method call list and the marking value of each method as the protocol body and returned to the client; Receive a method call request transmitted by a client, parse the transmission protocol in the method call request, and obtain a marking value under a preset field; A method corresponding to the marking value is queried locally, the method is called, and the calling result is obtained and returned to the client.

2. The method according to claim 1, characterized in that The tag value corresponds to the class name, method name, and parameter types involved in the method.

3. The method according to claim 2, characterized in that Before receiving the synchronization request for the method call list transmitted by the client, the method further includes: During the startup process, a binding relationship is established with the port number preset by the client; and The service is published to the registration center and marked as offline, so that after monitoring the connection request transmitted by the client, the service is marked as online; wherein a service includes one or more methods.

4. The method according to any one of claims 1 to 3, characterized in that Also includes: In response to a marking value change operation on one or more methods, replacing the locally cached marking value information with the changed current marking value information; A preset character string is used as a protocol header and the current marking value information is used as a protocol body, and a new transmission protocol is encapsulated and transmitted to the client to update the method marking value information.

5. The method according to claim 4, characterized in that After the operation of changing the marking value of one or more methods in response, the method further includes: Determine whether a hot deployment strategy for method call list synchronization is set; If not set, after restarting the server, verify whether the current marking value information of the one or more methods is consistent with the marking value information cached locally; or If set, after executing the hot deployment strategy, scan the current tag value information of each method to compare with the locally cached method tag value list.

6. The method according to any one of claims 1 to 3, characterized in that Also includes: During the process of processing the client request, if the connection with the client is detected to be disconnected, the heartbeat packets reported by the client are counted continuously; If the count exceeds the preset value and no heartbeat packet reported by the client is received, the client is determined to be offline and the connection relationship with the client is removed; After the network returns to normal and a connection request transmitted by the client is received, the connection relationship with the client is reestablished, and then after receiving a heartbeat packet transmitted by the client, the connection relationship is marked as a valid connection to perform a synchronization operation on the method call list for the client.

7. A request processing method, characterized in that: include: The client receives a method call request from the user and queries the marking value of the method locally; wherein the server receives a synchronization request for a method call list transmitted by the client, caches the class name, method name and parameter type involved in each method in the method call list locally and marks them; a new transmission protocol is encapsulated with a preset string as a protocol header, the method call list and the marking value of each method as a protocol body, and returned to the client; The marking value is used as the byte content of the preset field to encapsulate and obtain a transmission protocol; The transmission protocol is encapsulated into a new call request and transmitted to the server, and then the call result returned by the server is received and returned to the user.

8. The method according to claim 7, characterized in that The tag value corresponds to the class name, method name, and parameter type involved in the method; Before the client receives the user's request to call the method, it also includes: Transmit a synchronous request for the method call list to the server and receive the result returned by the server; If the protocol header of the transmission protocol in the result is a preset character string, determining that the result includes a method call list and a marking value for each method; The method call list and the marking value of each method are cached locally.

9. The method according to claim 8, characterized in that The transmitting of a synchronization request for a method call list to a server includes: Use load balancing to find the server with the smallest current load in the registration center; A connection request is transmitted to the server to establish a connection relationship with the server, and then a synchronization request for the method call list is transmitted to the server through the connection relationship.

10. The method according to any one of claims 7 to 9, characterized in that: Also includes: When the method tag value at the server is changed, the transmission protocol transmitted by the server is received and parsed to obtain the protocol header and the protocol body; If the protocol header is a preset character string, the locally cached method marking value information is updated based on the method marking value information in the protocol body.

11. The method according to any one of claims 7 to 9, characterized in that: Also includes: If a disconnection and reconnection occurs, the server that was last connected is determined, and the connection relationship with the server is reestablished based on the connection information between the server and the server; Encapsulate the heartbeat packet and transmit it to the server, transmit the synchronization request for the method call list to the server, and then receive the result returned by the server; If the protocol header of the transmission protocol in the result is a preset character string, determining that the result includes a method call list and a marking value for each method; Based on the method call list and the marking value of each method, the local cache is updated.

12. A request processing device, characterized in that: include: A synchronization module, used for receiving a synchronization request for a method call list transmitted by a client at the server end, caching the class name, method name and parameter type involved in each method in the method call list locally and marking them; A new transmission protocol is encapsulated with a preset string as the protocol header, the method call list and the marking value of each method as the protocol body and returned to the client; A parsing module, used for receiving a method call request transmitted by a client, parsing a transmission protocol in the method call request, and obtaining a marking value under a preset field; The calling module is used to locally query the method corresponding to the marking value, call the method, obtain the calling result and return it to the client.

13. A request processing device, characterized in that: include: The receiving module is used for receiving the user's method call request at the client end, and querying the marking value of the method locally; wherein the server end receives the synchronization request for the method call list transmitted by the client end, caches the class name, method name and parameter type involved in each method in the method call list locally and marks them; uses a preset string as the protocol header, the method call list and the marking value of each method as the protocol body, encapsulates a new transmission protocol and returns it to the client end; An encapsulation module, used for taking the marking value as the byte content of a preset field to encapsulate and obtain a transmission protocol; The transmission module is used to encapsulate the transmission protocol into a new call request and transmit it to the server, then receive the call result returned by the server, and return the call result to the user.

14. An electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 11.

15. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 11 is implemented.

Citation Information

Patent Citations

  • Data transmission method and device, terminal equipment and storage medium

    CN110446228A

  • Remote function calling processing method and device, electronic equipment and storage medium

    CN112395096A