Communication method and device between request end and response end

Abstract

The invention relates to a communication method and device between a request end and a response end, and the method comprises the steps: obtaining a unified standard communication process and a communication data protocol between the request end and the response end, and enabling the standard communication process to package a request function and a response function; and executing the standard communication process based on the request function and the communication data protocol to complete communication with the response end, the response end executing the standard communication process based on the response function and the communication data protocol. The code maintenance work can be simplified.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a communication method and device between a request end and a response end. Background Art

[0002] In the related art, the interaction between the request end and the responder end is generally through their respective communication mechanisms, but these two communication mechanisms are generally not interoperable. As the scale of demand grows, more and more methods need to be written on the request end for the responder to call.

[0003] For example, Android is the requesting end and Unity (a cross-platform game engine) is the responding end. The interaction between Unity and Android native code is currently mainly achieved through two methods: JNI and UnitySendMessage. Android sends data to Unity through the UnitySendMessage() function call, and Unity sends data to Android through JNI. As the demand scale grows, the Android side needs to write more and more methods for Unity to call.

[0004] As the number of writing methods increases, the code complexity becomes higher and higher, and the scalability gradually decreases, making code maintenance difficult. Summary of the invention

[0005] The present application provides a communication method and device between a request end and a response end to solve the problem of difficult code maintenance.

[0006] In a first aspect, the present application provides a communication method between a request end and a responder end, characterized in that the method comprises:

[0007] Acquire a unified standard communication process and communication data protocol with the responding end, wherein the standard communication process encapsulates a request function and a response function;

[0008] The standard communication process is executed based on the request function and the communication data protocol to complete the communication with the responding end, wherein the responding end executes the standard communication process based on the response function and the communication data protocol.

[0009] Optionally, executing the standard communication process based on the request function and the communication data protocol includes:

[0010] Constructing a request data packet including request parameters, wherein the request parameters include a request target indicating the responding end;

[0011] Calling the request function to pass in the request data packet and converting the request data packet into a request message, wherein the request message is in a data format specified by the communication data protocol;

[0012] According to the request target, the first communication channel provided by the responder is called to send the request message to the responder.

[0013] Optionally, the request parameter includes a request type and a request ID, the request ID is used to indicate the communication request number, and after calling the first communication channel provided by the responding end to send the request message to the responding end, the method further includes:

[0014] Determine a tag value of the request type in the request parameter, wherein the tag value is used to indicate whether the responding end is required to feedback a processing result;

[0015] If the tag value of the request type is the first tag value, it is determined that the responding end does not need to feedback the processing result and the process ends;

[0016] If the tag value of the request type is the second tag value, it is determined that the responder needs to feed back a processing result and start a child thread to receive the processing result; and a corresponding business operation is performed according to the response ID carried in the processing result.

[0017] In a second aspect, the present application provides a communication method between a request end and a response end, which is applied to the response end, and the method includes:

[0018] Acquire a unified standard communication process and communication data protocol with the requesting end, wherein the standard communication process encapsulates a response function and a request function;

[0019] The standard communication process is executed based on the response function and the communication data protocol to complete the communication with the request end, wherein the request end executes the standard communication process based on the request function and the communication data protocol.

[0020] Optionally, executing the standard communication process based on the response function and the communication data protocol includes:

[0021] Calling the response function to receive the request message sent by the request end;

[0022] Parsing request parameters in the request message, wherein the request parameters include a request path, a request body type, and a request body content;

[0023] dispatching the request message to at least one processing unit according to the request path;

[0024] The request body type and the request body content are processed by the processing unit to obtain and store a processing result, wherein a status code in the processing result is used to indicate whether the processing is successful.

[0025] Optionally, after obtaining and storing the processing result, the method further includes:

[0026] Determine a tag value of a request type in the request parameter;

[0027] If the tag value of the request type is the first tag value, the process ends;

[0028] If the tag value of the request type is the second tag value, the second communication channel provided by the requesting end is called, and the processing result carrying the response ID is fed back to the requesting end based on the response target, wherein the response target is used to indicate the requesting end, and the response ID is used to indicate which communication request the processing result corresponds to.

[0029] In a third aspect, the present application provides a communication device between a request end and a response end, which is applied to the request end, and the device includes:

[0030] A first acquisition module is used to acquire a unified standard communication process and communication data protocol with the responding end, wherein the standard communication process encapsulates a request function and a response function;

[0031] The first execution module is used to execute the standard communication process based on the request function and the communication data protocol to complete the communication with the responding end, wherein the responding end executes the standard communication process based on the response function and the communication data protocol.

[0032] In a fourth aspect, the present application provides a communication device between a request end and a response end, which is applied to the response end, and the device includes:

[0033] A second acquisition module is used to acquire a unified standard communication process and communication data protocol with the requesting end, wherein the standard communication process encapsulates a response function and a request function;

[0034] The second execution module is used to execute the standard communication process based on the response function and the communication data protocol to complete the communication with the request end, wherein the request end executes the standard communication process based on the request function and the communication data protocol.

[0035] In a fifth aspect, the present application provides an electronic device comprising: at least one communication interface; at least one bus connected to the at least one communication interface; at least one processor connected to the at least one bus; and at least one memory connected to the at least one bus.

[0036] In a sixth aspect, the present application also provides a computer storage medium storing computer executable instructions, wherein the computer executable instructions are used to execute the communication method between a requesting end and a responding end described in any one of the above items of the present application.

[0037] The above technical solution provided by the embodiment of the present application has the following advantages over the prior art: by implementing a standard communication process and a dedicated communication data protocol, all communications follow a unified process and format, and no matter how the function is expanded, the communication method of each new function is consistent, reducing the need to write additional code for specific situations and keeping the code clear and concise; and providing a clear and easy-to-use interface through request functions and response functions, so that developers can implement complex communication logic without worrying about the underlying implementation details, reducing the coupling of the code and improving the maintainability of the code. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0039] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0040] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0041] Figure 1 A schematic diagram of a communication system between a requester and a responder provided in an embodiment of the present application;

[0042] Figure 2 A flow chart of a method for communication between a request end and a response end provided in an embodiment of the present application;

[0043] Figure 3 A schematic diagram of the communication process between Android and Unity provided in an embodiment of the present application;

[0044] Figure 4 A schematic diagram of the structure of a communication device between a request end and a response end provided in an embodiment of the present application;

[0045] Figure 5A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0046] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0047] The disclosure below provides many different embodiments or examples to realize the different structures of the present application. In order to simplify the disclosure of the present application, the parts and settings of specific examples are described below. Of course, they are only examples, and the purpose is not to limit the present application. In addition, the present application can repeat reference numbers and / or letters in different examples. This repetition is for the purpose of simplification and clarity, and does not itself indicate the relationship between the various embodiments and / or settings discussed.

[0048] In order to solve the problem mentioned in the background technology, according to one aspect of an embodiment of the present application, an embodiment of communication between a request end and a response end is provided.

[0049] Optionally, in the embodiment of the present application, the communication method between the request end and the responder end can be applied to the following: Figure 1 In the hardware environment shown in FIG. 1 , a request end 101 and a response end 103 are formed. Figure 1 As shown, the request end and the responder end communicate with each other using a unified communication data protocol. The request end calls the first communication channel provided by the responder end to send the request content to the responder end. After the responder end processes the request content, it calls the second communication channel provided by the request end to feed back the processing result to the requester end. A database can be set on the request end or the responder end to provide data storage services.

[0050] A communication method between a requester and a responder in an embodiment of the present application may be executed by the requester 101 or by the responder 103 .

[0051] The following will be combined with specific implementation methods to describe in detail a communication method between a request end and a response end provided in an embodiment of the present application, taking application to the request end as an example. Figure 2 As shown, the specific steps are as follows:

[0052] Step 201: obtaining a unified standard communication process and communication data protocol with the responding end, wherein the standard communication process encapsulates a request function and a response function;

[0053] Step 202: Execute a standard communication process based on the request function and the communication data protocol to complete the communication with the responding end, wherein the responding end executes the standard communication process based on the response function and the communication data protocol.

[0054] This application provides a unified standard communication process and communication data protocol. The standard communication process means that all communication requests follow a unified pattern, which reduces the amount of additional code that needs to be written for specific situations. This simplifies the development process and reduces the possibility of errors, because all developers only need to focus on this standard process. In addition, the dedicated communication data protocol further standardizes the data format, so that data consistency can be guaranteed whether it is from the request end to the response end or from the response end to the request end. This unified data format simplifies the parsing and processing process, and also simplifies the development process.

[0055] In addition, the standard communication process encapsulates request functions and response functions. The requesting end can call the request function to execute the entire communication process, and the responding end can call the response function to execute the entire communication process. The encapsulated unified request function and response function provide a clear and easy-to-use interface. Developers do not need to care about the underlying implementation details. They only need to call these functions to implement complex communication logic, which greatly reduces the complexity of development and improves development efficiency.

[0056] Optionally, the requester and responder refer to two components that initiate and process requests during the communication process. They can be any entity that can exchange data through a certain protocol, specifically different software modules on the same physical device. Generally, the communication data protocols of the requester and responder are different. The requester or responder can be an Android platform, Unity platform, iOS platform, Web server, IoT device or embedded system, etc.

[0057] Exemplarily, the requesting end is Android and the responding end is Unity. Android calls the request function sendMessage() to send the request data packet to Unity in the specified data format. Unity uses the response function onReceiveMessage() to receive and process the request data packet to obtain the processing result. Since the data format used by the requesting end and the responding end is the same, the responding end can effectively process the request data packet.

[0058] This application implements standard communication processes and dedicated communication data protocols so that all communications follow a unified process and format. No matter how the functions are expanded, the communication method of each new function is consistent, reducing the need to write additional code for specific situations and keeping the code clear and concise; and provides clear and easy-to-use interfaces through request functions and response functions, so that developers can implement complex communication logic without worrying about the underlying implementation details, reducing the coupling of the code and improving the maintainability of the code.

[0059] This application uses a unified standard communication process and communication data protocol. The standard communication process helps to simplify the development process and reduce the chance of errors. Developers only need to focus on business logic and parameter settings without having to worry about underlying communication details, thereby improving development efficiency. The communication data protocol enhances the compatibility and interoperability of the system, and can easily adapt to existing communication mechanisms even if new platforms or technologies are introduced in the future. For example, if the iOS platform needs to join, as long as the iOS side also follows the same data communication protocol, it can seamlessly connect to the existing Android and Unity communication mechanisms.

[0060] In this application, the communication data protocol uses a dedicated data format, such as SAUP (Seres Android Unity Protocol) message, to standardize the data transmission between Android and Unity. The protocol defines the request part (Request) and the response part (Response) to ensure that the data transmitted between the request end and the responder end has a unified format. The contents of the request part and the response part are as follows.

[0061] The request part is defined as follows:

[0062] 1.request-type: request type, which is divided into SendOnly (first tag value) or ResponseRequire (second tag value). SendOnly means sending only notification and no response is required from the responder. ResponseRequire means initiating a communication request and requiring the responder to reply with the processing result.

[0063] 2. Request ID: used to identify a communication request, generated by the client, starts from 1 and automatically increases.

[0064] 3.target: request target, for example, Unity or Android. If a communication request is initiated from Android to Unity, this field is Unity; if a communication request is initiated from Unity to Android, this field is Android.

[0065] 4.path: request path, used to indicate what logic the recipient needs to execute for this request. For example, CarModel / Control / Window / ChangeWindowState, this path indicates that the window state needs to be modified, that is, the window needs to be opened or closed.

[0066] 5.Content-type: request body type, such as json or text.

[0067] 6. content-data: request body content, depending on the type set in content-type, such as a JSON string or plain text characters.

[0068] The response part (Response) is defined as follows:

[0069] 1. Response ID: used to tell the requester which request this response is the result of.

[0070] 2.target: response target, such as Unity or Android. If the Android side responds to Unity's request, this field is Android; if the Unity side responds to Android's request, this field is Unity.

[0071] 3.status-code: status code, 0-processing failed, 1-processing successful.

[0072] 4.Content-type: response body type, such as json or text.

[0073] 5. content-data: the content of the response body, according to the type in content-type, such as a JSON string or plain text characters.

[0074] As an optional implementation, in step 202, the requesting end executes a standard communication process based on the request function and the communication data protocol, including the following steps:

[0075] Step S11: construct a request data packet including request parameters, wherein the request parameters include a request target indicating a responding end.

[0076] The requester collects all necessary request parameters according to the business logic, including request type, request target, request ID, request path, request body type and request body content, and then organizes these request parameters in a predefined format to ensure that each parameter has a clear identifier and value. Finally, the formatted parameters are packaged into a complete data structure to form a request data packet that complies with the specification. The design of the request data packet needs to contain all necessary information so that the responder can correctly parse and process the request; standardized request parameters reduce the time and complexity of parsing the request on the responder side, and improve the response speed.

[0077] For example, in the smart cockpit system, when a command to change the window status needs to be sent from Android to Unity, the request parameters may include target (the request target is Unity), path (the request path is CarModel / Control / Window / ChangeWindowState), and content-data (specific status values ​​such as open or closed). In addition, it must also include a unique request ID to identify this communication request, and request-type to indicate whether a response is required.

[0078] Step S12: calling the request function to input the request data packet and converting the request data packet into a request message, wherein the request message is in a data format specified by the communication data protocol.

[0079] The request end calls the encapsulated request function and passes in the constructed request data packet. The request function formats the parameters in the request data packet according to the requirements of the communication data protocol and generates a standard request message. This process not only ensures the consistency and integrity of the data, but also facilitates subsequent transmission and parsing. For example, when the Android side initiates a request to modify the window status, the request function converts the previously constructed data packet into a request message in JSON format so that it can be transmitted on the network and correctly parsed by the Unity side.

[0080] Optionally, a data verification step may be added during the conversion process to ensure the legitimacy and integrity of the request message and to prevent invalid or erroneous data from affecting system operation.

[0081] Step S13: according to the request target, calling the first communication channel provided by the responding end to send the request message to the responding end.

[0082] The requesting end determines the first communication channel provided by the responding end according to the target field (request target) in the request message, and then calls the first communication channel to send the request message to ensure that the data can reach the responding end accurately.

[0083] For example, when the request target is Unity, the Android side will call the UnitySendMessage() function provided by the responder to send the message to Unity for processing. Conversely, if the request target is Android, the Unity side will call the corresponding method through JNI to send the request to the Android side.

[0084] In this application, through standardized data packet construction and conversion processes, the communication data protocol simplifies the interaction between the request end and the response end, reduces the amount of code that developers need to write, and improves development efficiency. Secondly, since all communications follow the same protocol, data consistency and predictability can be ensured regardless of the complexity of the request, which is a significant advantage for maintenance and debugging. In addition, the use of dedicated communication channels can increase the speed and reliability of data transmission and reduce delays and error rates. Finally, this structured approach also helps to improve the maintainability and scalability of the system, because when adding new functions or modifying existing functions, you only need to adjust the corresponding data packet structure and processing logic without having to reconstruct the entire communication system. For example, if you need to add a request to control the seat heating function, you only need to add new request parameters in the established format without significantly changing the existing code.

[0085] As an optional implementation mode, the request parameter includes a request type and a request ID, and the request ID is used to indicate the communication request number. After the first communication channel provided by the responding end is called to send the request message to the responding end, the method further includes the following steps:

[0086] Step S21: Determine the tag value of the request type in the request parameter, wherein the tag value is used to indicate whether the responding end is required to feedback the processing result.

[0087] When the request data packet is constructed and ready to be sent, it is first necessary to check the request-type field in the request parameters to determine the tag value of the request type. The value of this field (i.e. the tag value of the request type) is used to indicate whether the responder needs to feedback the processing result.

[0088] For example, according to the SAUP protocol, the request-type field has two optional values: SendOnly (first tag value) and ResponseRequire (second tag value). The former means only sending a notification, and no response is required from the responder; the latter means initiating a communication request, and the responder needs to reply with the processing result.

[0089] Different business scenarios determine which request type to use. For operations that do not require high real-time performance or do not require immediate feedback, such as logging or status updates, the SendOnly type can be used to simplify the process; for interactive operations that require immediate response, such as control instructions or query requests, the ResponseRequire type should be selected to ensure that the operation is completed successfully. For example, in a smart cockpit system, if a notification to update the vehicle status is sent from Android to Unity, it may not be necessary to receive a confirmation message from Unity immediately; if the status of a specific function is queried, it is necessary to wait for Unity to return a specific result.

[0090] By clearly distinguishing the tag values ​​of request types, communication efficiency can be optimized without affecting the core business logic. For operations that do not need to wait for responses, ending the process directly can reduce unnecessary resource usage and improve overall performance. At the same time, this method also increases the flexibility of the system, allowing developers to flexibly adjust request types according to actual needs and adapt to application requirements in different scenarios.

[0091] Step S22: If the tag value of the request type is the first tag value, it is determined that there is no need for the responding end to feedback the processing result and the process ends.

[0092] When the request type is determined to be SendOnly (i.e., the first tag value), it indicates that this request is a one-way notification and does not need to wait for any feedback from the responding end. In this case, once the request message is successfully sent to the responding end, it can be considered that the communication is completed and the client can immediately end the relevant processing flow. Using SendOnly type requests can reduce the system burden, especially in high-concurrency scenarios, reducing the pressure on the server side. At the same time, the fast response speed can also enhance user satisfaction and make the entire interaction process more efficient.

[0093] For example, in a smart home control system, when a user sets a timed light shutdown through a mobile phone app, he or she only needs to synchronize the setting to the home gateway without having to wait for the specific execution result, because even if there is no immediate feedback, the user knows that the operation intention has been received.

[0094] Step S23: If the tag value of the request type is the second tag value, it is determined that the responding end needs to feedback the processing result and a subthread is started to receive the processing result; and corresponding business operations are performed according to the response ID carried in the processing result.

[0095] If the request type is marked as ResponseRequire (i.e. the second tag value), it means that this is a two-way communication request. The requesting end not only needs to send the request, but also needs to wait for the processing result of the responding end. In order not to affect the operation of the main thread, a sub-thread is usually opened to receive and process these results. For example, in an online game scenario, when a player sends a request to purchase an item, the client not only needs to send a purchase command to the server, but also needs to wait for the server to confirm whether the transaction is successful, and update the local status according to the returned result.

[0096] Optionally, to avoid indefinite waiting, a reasonable timeout (such as 5000 milliseconds) can be set. If no response is received within the specified time, it is considered a communication failure and appropriate measures are taken, such as resending the request or prompting the user with failure information. If the child thread receives the processing result within the specified time, it matches the corresponding request according to the response ID carried in the result and performs the corresponding business operation, such as updating the UI interface, modifying the database record, etc.

[0097] This application uses child threads to process requests that require responses. This asynchronous processing method not only improves the system's response speed, but also enhances stability. Even if a response is not received in time in some cases, the system can respond reasonably through a timeout mechanism to avoid falling into an infinite loop or unresponsive state. In addition, by matching the response ID with the corresponding request ID, it is ensured that each request and its corresponding processing result can accurately correspond, thereby maintaining the consistency and integrity of the data.

[0098] As an optional implementation, in step 202, the responding end executes a standard communication process based on the response function and the communication data protocol, including:

[0099] Step S31: calling the response function to receive the request message sent by the requesting end.

[0100] After the requester sends the request message, the responder needs to receive the message through a specific response function. This step ensures that the request information can be accurately captured by the responder and enter the processing flow. For example, in the smart cockpit system, when the Android side issues a command to modify the window status, the Unity side must be able to receive this command in time and be ready for the next step of parsing and processing.

[0101] The response function class is responsible for monitoring the data flow on the network channel. Once a new request message is detected, the receiving process is immediately started. After successfully receiving the request message, the response function may return a simple confirmation signal to the requesting end to inform the other party that the message has been received, which helps to improve the reliability of communication.

[0102] By receiving request messages through a dedicated response function, each request can be effectively captured to avoid information loss due to network fluctuations or other factors. In addition, this design enhances the flexibility and scalability of the system. Even if new request types are added or existing communication protocols are changed in the future, only the response function needs to be updated to be compatible with the new changes without large-scale changes to other modules.

[0103] Step S32: Parse the request parameters in the request message, wherein the request parameters include the request path, the request body type and the request body content.

[0104] After the responder receives the request message, the next step is to parse it and extract key request parameters, including request path, request body type, and request body content. These parameters provide necessary guidance for subsequent specific processing. For example, assuming the request path is CarModel / Control / Window / ChangeWindowState, it indicates that this is a request for changing the state of the vehicle model control window; if the request body type is JSON, it means that the following content is data encoded in JSON format.

[0105] In this application, by parsing the response function, the original request message can be converted into the data form required by the specific business logic, which simplifies the processing process. Clear parameter definitions and formatting rules reduce the possibility of misunderstanding and improve the accuracy of processing. At the same time, this standardized parsing process also facilitates future maintenance and upgrades. Any adjustment to the request parameter structure can be concentrated in this step without affecting the functions of other parts.

[0106] Step S33: dispatching the request message to at least one processing unit according to the request path.

[0107] After parsing the request parameters, the responder assigns the task to the corresponding processing unit according to the request path. This process can be done by looking up a predefined mapping table or using a dynamic routing algorithm. Each processing unit is designed for a specific function or module, and each has its own independent processing logic. For example, for a request with the path CarModel / Control / Window / ChangeWindowState, it will be dispatched to the processing unit responsible for vehicle model control, which focuses on processing all requests related to the window status.

[0108] In this application, the task distribution mechanism based on the request path realizes the refined management of request processing, ensuring that each request can be executed by the most suitable processing unit. This approach not only improves the processing efficiency, but also enhances the modularity of the system, making the coupling between different functions lower, and facilitating separate development, testing and deployment. For example, if a new control function needs to be added, only a new processing unit needs to be added without affecting the normal operation of the existing functions.

[0109] Step S34: The request body type and the request body content are processed by the processing unit to obtain and store the processing result, wherein the status code in the processing result is used to indicate whether the processing is successful.

[0110] After receiving the request message, the processing unit begins to actually process the request body type and request body content. According to the specific requirements of the request, the processing unit may need to perform a series of complex logical operations, such as calculations, database queries, and external service calls. Finally, the processing unit will generate a processing result including a status code and store it for subsequent use. A status code of 1 indicates successful processing, and a status code of 0 indicates failed processing. For example, if the request is to query the status of a vehicle component, the processing unit will query the current status information and return a status code indicating success (such as 1) and the specific query result.

[0111] In this application, the request is specifically processed by the processing unit to ensure that each request receives an appropriate response. The existence of the status code provides a clear result feedback to the requesting end, enabling it to take the next step based on the processing situation. In addition, the storage of processing results also provides basic support for functions such as logging and audit tracking, which helps to improve the transparency and traceability of the system. For example, in the smart cockpit system, users can understand the actual execution of each operation by viewing the processing results, so as to better understand the status of the vehicle.

[0112] As an optional implementation, after obtaining and storing the processing result, the method further includes:

[0113] Step S41: Determine the tag value of the request type in the request parameter.

[0114] When the responder completes processing the request, it first needs to check the request-type field in the request parameters to determine whether the request requires feedback of the processing result. The value of this field (i.e., the tag value) is used to indicate the type of request and determines the direction of the subsequent process. For example, in the smart cockpit system, if Android sends a request to Unity to query the current speed of the vehicle, the request may be marked as ResponseRequire, indicating that Unity needs to return specific query results.

[0115] Step S42: If the tag value of the request type is the first tag value, the process ends.

[0116] When the responder determines that the request type is SendOnly (i.e., the first tag value), it indicates that this request is a one-way notification and no feedback from the responder is required. In this case, once the responder completes the request processing, the communication is considered to be completed and the responder can immediately end the relevant processing flow.

[0117] Step S43: If the tag value of the request type is the second tag value, the second communication channel provided by the requesting end is called, and the processing result carrying the response ID is fed back to the requesting end based on the response target, wherein the response target is used to indicate the requesting end, and the response ID is used to indicate which communication request the processing result corresponds to.

[0118] If the request type is marked as ResponseRequire (i.e., the second tag value), it means that this is a two-way communication request. The client not only needs to send the request, but also needs to wait for the processing result of the responder. To achieve this process, the responder will call the second communication channel provided by the requester and feed back the processing result including the response ID to the requester.

[0119] The responder constructs a processing result including a response ID to ensure that each processing result can accurately correspond to a specific request. The response ID is generated by the responder and automatically increases from 1 to ensure uniqueness.

[0120] This application uses the response ID to identify each processing result, ensuring that each request and its corresponding processing result can accurately correspond, thereby maintaining the consistency and integrity of the data. For example, in the smart cockpit system, users can quickly send status update requests with a simple click. At the same time, for important control instructions, the system can ensure that they are correctly processed and feedback results in a timely manner, providing users with a smoother and more reliable user experience.

[0121] This application takes Android sending a communication request to Unity as an example to illustrate the communication process. Figure 3 As shown, the following steps are included.

[0122] Step 1: The Android side constructs a request data packet, sets parameters such as request-type, request ID, target, path, content-type, and content-data, and calls the sendMessage function to pass in the request data packet. The sendMessage function converts the request data packet into a request message.

[0123] Step 2: The Android end calls the UnitySendMessage function provided by Unity to send the request message to the Unity end.

[0124] Step 3: The Android side determines the request-type field. If it is SendOnly, the process on the Android side ends directly. If it is ResponseRequire, a child thread needs to be started to wait for the Unity side to return the processing result. If the result is not received from the Unity side after a certain period of time, it is determined that the communication request has timed out. The default timeout period is 5000ms. After the timeout, the next step can be performed according to the business logic, and you can choose to re-request or directly determine it as a failure and prompt it.

[0125] Step 4: After receiving the request message, Unity parses the request message into a processable data format and distributes the data to different scripts based on the value of the path field. The script reads the value in content-data, obtains the data passed from the Android side, processes the data, and caches the processing results for future use.

[0126] Step 5: After the Unity side completes the processing, determine the value of the request-type field in the request message. If it is SendOnly, the process on the Unity side ends and the entire process ends; if it is ResponseRequire, the processing result needs to be returned to the Android side through JNI.

[0127] Step 6: The Android side receives the processing result returned by the Unity side. It can determine which request the processing result is through the response ID, and execute the next step logic according to the processing result. The whole process ends here.

[0128] In this application, by defining standard communication processes and communication data protocols, the communication between the request end and the response end is standardized and unified, which reduces the writing of functions, keeps the code clear and concise, helps code maintenance, and improves development efficiency. In addition, the unified data format helps to improve scalability, breaking the constraints of related technologies that can only send messages in one direction, and realizing two-way communication between the request end and the response end.

[0129] Based on the same technical concept, the present application provides a communication device between a request end and a response end, which is applied to the request end, such as Figure 4 As shown, the device comprises:

[0130] The first acquisition module 401 is used to acquire a unified standard communication process and communication data protocol with the responding end, wherein the standard communication process encapsulates a request function and a response function;

[0131] The first execution module 402 is used to execute a standard communication process based on a request function and a communication data protocol to complete communication with a responding end, wherein the responding end executes a standard communication process based on a response function and a communication data protocol.

[0132] Optionally, the first execution module 402 is used to:

[0133] Constructing a request data packet including request parameters, wherein the request parameters include a request target indicating a responding end;

[0134] Calling the request function to pass in a request data packet and converting the request data packet into a request message, wherein the request message is in a data format specified by the communication data protocol;

[0135] According to the request target, the first communication channel provided by the responder is called to send the request message to the responder.

[0136] Optionally, the request parameter includes a request type and a request ID, and the request ID is used to indicate the communication request number. The device is further used to:

[0137] Determine the tag value of the request type in the request parameter, wherein the tag value is used to indicate whether the responder needs to feedback the processing result;

[0138] If the tag value of the request type is the first tag value, it is determined that there is no need for the responding end to feedback the processing result and the process ends;

[0139] If the tag value of the request type is the second tag value, it is determined that the responding end needs to feedback the processing result and start a child thread to receive the processing result; and the corresponding business operation is executed according to the response ID carried in the processing result.

[0140] Based on the same technical concept, the present application provides a communication device between a request end and a response end, which is applied to the response end, and the device includes:

[0141] A second acquisition module is used to acquire a unified standard communication process and communication data protocol with the requesting end, wherein the standard communication process encapsulates a response function and a request function;

[0142] The second execution module is used to execute a standard communication process based on the response function and the communication data protocol to complete the communication with the requesting end, wherein the requesting end executes the standard communication process based on the request function and the communication data protocol.

[0143] Optionally, the second execution module is used to:

[0144] Call the response function to receive the request message sent by the requester;

[0145] Parsing request parameters in the request message, where the request parameters include request path, request body type, and request body content;

[0146] Dispatching the request message to at least one processing unit according to the request path;

[0147] The request body type and the request body content are processed by the processing unit to obtain and store the processing result, wherein the status code in the processing result is used to indicate whether the processing is successful.

[0148] Optionally, the device is also used for:

[0149] Determine the tag value of the request type in the request parameter;

[0150] If the tag value of the request type is the first tag value, the process ends;

[0151] If the tag value of the request type is the second tag value, the second communication channel provided by the requesting end is called, and the processing result carrying the response ID is fed back to the requesting end based on the response target, wherein the response target is used to indicate the requesting end, and the response ID is used to indicate which communication request the processing result corresponds to.

[0152] like Figure 5 As shown, an embodiment of the present application provides an electronic device, including a processor 501, a communication interface 502, a memory 503 and a communication bus 504, wherein the processor 501, the communication interface 502, and the memory 503 communicate with each other through the communication bus 504.

[0153] The memory 503 is used to store computer programs.

[0154] In one embodiment of the present application, the processor 501 is used to implement the communication method between the request end and the responder end provided by any one of the aforementioned method embodiments when executing the program stored in the memory 503.

[0155] An embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of the communication method between the request end and the responder end provided in any of the aforementioned method embodiments are implemented.

[0156] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0157] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a general hardware platform, and of course, by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0158] It should be understood that the terms used herein are only for the purpose of describing specific example embodiments and are not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "one", "an" and "said" as used herein may also be meant to include plural forms. The terms "include", "comprise", "contain", and "have" are inclusive, and therefore specify the existence of stated features, steps, operations, elements and / or parts, but do not exclude the existence or addition of one or more other features, steps, operations, elements, parts, and / or combinations thereof. The method steps, processes, and operations described herein are not interpreted as necessarily requiring them to be performed in the specific order described or illustrated, unless the execution order is clearly indicated. It should also be understood that additional or alternative steps may be used.

[0159] The above description is only a specific implementation of the present application, so that those skilled in the art can understand or implement the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest range consistent with the principles and novel features applied for herein.

Claims

1. A communication method between a request end and a response end, characterized in that: Applied to the requesting end, the method includes: Acquire a unified standard communication process and communication data protocol with the responding end, wherein the standard communication process encapsulates a request function and a response function; The standard communication process is executed based on the request function and the communication data protocol to complete the communication with the responding end, wherein the responding end executes the standard communication process based on the response function and the communication data protocol.

2. The method according to claim 1, characterized in that: Executing the standard communication process based on the request function and the communication data protocol includes: Constructing a request data packet including request parameters, wherein the request parameters include a request target indicating the responding end; Calling the request function to pass in the request data packet and converting the request data packet into a request message, wherein the request message is in a data format specified by the communication data protocol; According to the request target, the first communication channel provided by the responder is called to send the request message to the responder.

3. The method according to claim 2, characterized in that The request parameters include a request type and a request ID, wherein the request ID is used to indicate the communication request number. After calling the first communication channel provided by the responding end to send the request message to the responding end, the method further includes: Determine a tag value of the request type in the request parameter, wherein the tag value is used to indicate whether the responding end is required to feedback a processing result; If the tag value of the request type is the first tag value, it is determined that the responding end does not need to feedback the processing result and the process ends; If the tag value of the request type is the second tag value, it is determined that the responder needs to feed back a processing result and start a child thread to receive the processing result; and a corresponding business operation is performed according to the response ID carried in the processing result.

4. A communication method between a request end and a response end, characterized in that: Applied to the responding end, the method includes: Acquire a unified standard communication process and communication data protocol with the requesting end, wherein the standard communication process encapsulates a response function and a request function; The standard communication process is executed based on the response function and the communication data protocol to complete the communication with the request end, wherein the request end executes the standard communication process based on the request function and the communication data protocol.

5. The method according to claim 4, characterized in that Executing the standard communication process based on the response function and the communication data protocol includes: Calling the response function to receive the request message sent by the request end; Parsing request parameters in the request message, wherein the request parameters include a request path, a request body type, and a request body content; dispatching the request message to at least one processing unit according to the request path; The request body type and the request body content are processed by the processing unit to obtain and store a processing result, wherein a status code in the processing result is used to indicate whether the processing is successful.

6. The method according to claim 5, characterized in that After obtaining and storing the processing result, the method further includes: Determine a tag value of a request type in the request parameter; If the tag value of the request type is the first tag value, the process ends; If the tag value of the request type is the second tag value, the second communication channel provided by the requesting end is called, and the processing result carrying the response ID is fed back to the requesting end based on the response target, wherein the response target is used to indicate the requesting end, and the response ID is used to indicate which communication request the processing result corresponds to.

7. A communication device between a request end and a response end, characterized in that: Applied to the requesting end, the device comprises: A first acquisition module is used to acquire a unified standard communication process and communication data protocol with the responding end, wherein the standard communication process encapsulates a request function and a response function; The first execution module is used to execute the standard communication process based on the request function and the communication data protocol to complete the communication with the responding end, wherein the responding end executes the standard communication process based on the response function and the communication data protocol.

8. A communication device between a request end and a response end, characterized in that: Applied to the responding end, the device comprises: A second acquisition module is used to acquire a unified standard communication process and communication data protocol with the requesting end, wherein the standard communication process encapsulates a response function and a request function; The second execution module is used to execute the standard communication process based on the response function and the communication data protocol to complete the communication with the request end, wherein the request end executes the standard communication process based on the request function and the communication data protocol.

9. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, for implementing the method described in any one of claims 1-3 or 4-6 when executing a program stored in a memory.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method described in any one of claims 1-3 or 4-6 is implemented.

Images