Communication method and apparatus between a requesting end and a responding end

Abstract

The application relates to a communication method and device between a request end and a response end, and the method comprises the following steps: obtaining a unified standard communication process and a communication data protocol between the response end, wherein a request function and a response function are encapsulated in the standard communication process; and performing the standard communication process based on the request function and the communication data protocol to complete communication between the request end and the response end, wherein the response end performs the standard communication process based on the response function and the communication data protocol. The application can simplify the maintenance work of codes.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication method and apparatus between a requesting end and a responding end. Background Technology

[0002] In related technologies, the interaction between the requesting end and the responding end is generally through their respective communication mechanisms. However, these two communication mechanisms are generally not compatible. As the scale of demand grows, it is necessary to write more and more methods on the requesting end for the responding end to call.

[0003] For example, Android acts as the requesting end, and Unity (a cross-platform game engine) acts as the responding end. Currently, the interaction between Unity and Android's native code is 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 scale of demand 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 becomes more complex, its scalability gradually decreases, and code maintenance becomes difficult. Summary of the Invention

[0005] This application provides a communication method and apparatus between a requesting end and a responding end to solve the problem of difficult code maintenance.

[0006] In a first aspect, this application provides a communication method between a requesting end and a responding end, characterized in that the method includes:

[0007] A unified standard communication process and communication data protocol are obtained between the acquiring and responding ends, wherein the standard communication process encapsulates request functions and response functions;

[0008] The standard communication process is executed based on the request function and the communication data protocol to complete 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] Construct a request data packet containing request parameters, wherein the request parameters include a request target indicating the responding end;

[0011] The request function is invoked, passing in the request data packet and converting the request data packet into a request message, wherein the request message is in the data format specified by the communication data protocol;

[0012] Based on the requested target, the request message is sent to the response end by invoking the first communication channel provided by the response end.

[0013] Optionally, the request parameters include a request type and a request ID, whereby the request ID indicates the number of communication requests. After the request message is sent to the response end via the first communication channel provided by the response end, the method further includes:

[0014] Determine the flag value of the request type in the request parameters, wherein the flag value is used to indicate whether the response end needs to provide a processing result;

[0015] If the flag value of the request type is the first flag value, then it is determined that no processing result is needed from the responding end and the process ends;

[0016] If the flag value of the request type is the second flag value, then it is determined that the response end needs to provide a processing result and a sub-thread is started to receive the processing result; the corresponding business operation is executed according to the response ID carried in the processing result.

[0017] Secondly, this application provides a communication method between a requesting end and a responding end, applied to the responding end, the method comprising:

[0018] Obtain a unified standard communication process and communication data protocol between the client and the requesting client, wherein the standard communication process encapsulates response functions and request functions;

[0019] The standard communication process is executed based on the response function and the communication data protocol to complete communication with the requesting end, wherein the requesting 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] Call the response function to receive the request message sent by the requesting end;

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

[0023] The request message is dispatched to at least one processing unit according to the request path;

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

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

[0026] Determine the flag value for the request type in the request parameters;

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

[0028] If the tag value of the request type is the second tag value, then the second communication channel provided by the requesting end is invoked, and the processing result carrying the response ID is fed back to the requesting end based on the response target. 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] Thirdly, this application provides a communication device between a requesting end and a responding end, applied to the requesting end, the device comprising:

[0030] The first acquisition module is used to acquire a unified standard communication process and communication data protocol between the client and the responder, 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 response end, wherein the response end executes the standard communication process based on the response function and the communication data protocol.

[0032] Fourthly, this application provides a communication device between a requesting end and a responding end, applied to the responding end, the device comprising:

[0033] The second acquisition module is used to acquire a unified standard communication process and communication data protocol between the client and the requesting client, 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 requesting end, wherein the requesting end executes the standard communication process based on the request function and the communication data protocol.

[0035] Fifthly, this 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] Sixthly, this application also provides a computer storage medium storing computer-executable instructions for executing the communication method between the requesting end and the responding end as described in any of the preceding claims of this application.

[0037] Compared with the prior art, the technical solutions provided in this application have the following advantages: by implementing standard communication processes and dedicated communication data protocols, all communication follows 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. Furthermore, by providing clear and easy-to-use interfaces through request and response functions, developers can implement complex communication logic without worrying about the underlying implementation details, reducing code coupling and improving code maintainability. Attached Figure Description

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

[0039] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0040] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0041] Figure 1 A schematic diagram of the communication system between the requesting and responding ends provided in an embodiment of this application;

[0042] Figure 2 A flowchart illustrating a method for communication between a requesting end and a responding end, provided in an embodiment of this application;

[0043] Figure 3 This is a schematic diagram of the communication process between Android and Unity provided in an embodiment of this application;

[0044] Figure 4 A schematic diagram of the structure of a communication device between a requesting end and a responding end provided in an embodiment of this application;

[0045] Figure 5This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0047] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0048] To address the problems mentioned in the background art, according to one aspect of the embodiments of this application, an embodiment of communication between a requesting end and a responding end is provided.

[0049] Optionally, in the embodiments of this application, the communication method between the requesting end and the responding end described above can be applied to, for example... Figure 1 The hardware environment shown consists of request terminal 101 and response terminal 103. For example... Figure 1 As shown, the requesting end and the responding end communicate using a unified communication data protocol. The requesting end calls the first communication channel provided by the responding end to send the request content to the responding end. After processing the request content, the responding end calls the second communication channel provided by the requesting end to send the processing result back to the requesting end. A database can be set up on either the requesting end or the responding end to provide data storage services.

[0050] A communication method between a requesting end and a responding end in this application embodiment can be executed by the requesting end 101 or by the responding end 103.

[0051] The following will describe in detail a communication method between a requesting end and a responding end provided in this application embodiment, taking an application to the requesting end as an example. Figure 2 As shown, the specific steps are as follows:

[0052] Step 201: Obtain the unified standard communication process and communication data protocol between the responder and the responder. The standard communication process encapsulates request functions and response functions.

[0053] Step 202: Execute the standard communication process based on the request function and 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 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, reducing the amount of extra code that needs to be written for specific situations. This simplifies the development process and reduces the possibility of errors, as all developers only need to focus on this standard process. In addition, the dedicated communication data protocol further standardizes the data format, ensuring data consistency whether data is transmitted from the requesting end to the responding end or from the responding end to the requesting end. This unified data format simplifies the parsing and processing processes, as well as the development process.

[0055] In addition, the standard communication process encapsulates request 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. Encapsulating unified request and response functions provides a clear and easy-to-use interface. Developers do not need to care about the underlying implementation details. They can implement complex communication logic simply by calling these functions. This greatly reduces the complexity of development and improves development efficiency.

[0056] Optionally, the requesting end and the responding end refer to the two components that initiate and process the request during communication. They can be any entities capable of exchanging data via a certain protocol, specifically different software modules on the same physical device. Generally, the communication data protocols of the requesting end and the responding end are different. The requesting end or the responding end can be an Android platform, a Unity platform, an iOS platform, a web server, an IoT device, or an embedded system, etc.

[0057] For example, 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 and obtain the processing result. Since the requesting end and the responding end use the same data format, the responding end can effectively process the request data packet.

[0058] This application implements a standard communication process and a dedicated communication data protocol, ensuring that all communication follows a unified process and format. Regardless of how the functionality is expanded, the communication method for each new function remains consistent, reducing the need to write additional code for specific situations and keeping the code clear and concise. Furthermore, it provides clear and easy-to-use interfaces through request and response functions, allowing developers to implement complex communication logic without worrying about the underlying implementation details, reducing code coupling and improving code maintainability.

[0059] This application uses a unified standard communication process and data protocol. The standard communication process simplifies the development process and reduces the chance of errors. Developers only need to focus on business logic and parameter settings, without needing to worry about the underlying communication details, thus improving development efficiency. The communication data protocol enhances the system's compatibility and interoperability, allowing for easy adaptation to existing communication mechanisms even when new platforms or technologies are introduced in the future. For example, if the iOS platform needs to be added, as long as the iOS side also follows the same data communication protocol, it can seamlessly connect to existing Android and Unity communication mechanisms.

[0060] In this application, the communication data protocol adopts a dedicated data format, such as the SAUP (Seres Android UnityProtocol) message, to standardize data transmission between Android and Unity. This protocol defines a request section and a response section to ensure that the data transmitted between the requesting and responding ends has a uniform format. The contents of the request and response sections are as follows.

[0061] The request section is defined as follows:

[0062] 1. request-type: Request type, which is either SendOnly (first flag value) or ResponseRequire (second flag value). SendOnly means that only a notification is sent and no response is required from the responding end. ResponseRequire means that a communication request is initiated and a response from the responding end is required to provide the processing result.

[0063] 2. Request ID: Used to identify a communication request. It is generated by the client, starts from 1 and increments automatically.

[0064] 3. target: The target of the request, such as Unity or Android. If the communication request is initiated from the Android side to the Unity side, this field is Unity; if the communication request is initiated from the Unity side to the Android side, this field is Android.

[0065] 4. path: The request path, used to indicate what logic the receiver needs to execute in this request. For example, CarModel / Control / Window / ChangeWindowState indicates that the window state needs to be modified, such as opening or closing the window.

[0066] 5. content-type: The type of the request body, such as json or text.

[0067] 6. content-data: The request body content, which is determined by the type set in content-type, such as JSON string or plain text.

[0068] The response section is defined as follows:

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

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

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

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

[0073] 5. content-data: The response body content, which depends on the type specified in content-type, such as a JSON string or plain text characters.

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

[0075] Step S11: Construct a request data packet containing request parameters, wherein the request parameters include the request target indicating the response end.

[0076] The requesting end collects all necessary request parameters according to business logic. These parameters include request type, request target, request ID, request path, request body type, and request body content. These parameters are then organized according to a predefined format, ensuring each parameter has a clear identifier and value. Finally, the formatted parameters are packaged into a complete data structure, forming a standardized request data packet. This request data packet is designed to contain all necessary information so that the responding end can correctly parse and process the request. Standardized request parameters reduce the time and complexity of request parsing on the responding end, improving response speed.

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

[0078] Step S12: Call the request function, pass in the request data packet, and convert the request data packet into a request message, wherein the request message is in the data format specified by the communication data protocol.

[0079] The requesting side calls a pre-packaged request function, passing in the constructed request data packet. Internally, the request function formats the parameters in the request data packet according to the requirements of the communication data protocol, generating a standard request message. This process not only ensures data consistency and integrity 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 JSON-formatted request message, enabling transmission over the network and correct parsing by the Unity side.

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

[0081] Step S13: Based on the request target, call the first communication channel provided by the response end to send the request message to the response end.

[0082] The requesting end determines the first communication channel provided by the responding end based on 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 response side to send the message to Unity for processing. Conversely, if the request target is Android, the Unity side will call the corresponding method via JNI to send the request to the Android side.

[0084] In this application, a standardized data packet construction and conversion process simplifies the interaction between the requesting and responding ends through the communication data protocol, reducing the amount of code developers need to write and improving development efficiency. Secondly, since all communication follows the same protocol, data consistency and predictability are ensured regardless of request complexity, which is a significant advantage for maintenance and debugging. Furthermore, using a dedicated communication channel improves data transmission speed and reliability, reducing latency and error rates. Finally, this structured approach also helps improve system maintainability and scalability, because adding new features or modifying existing features only requires adjusting the corresponding data packet structure and processing logic, without having to refactor the entire communication system. For example, if a new request to control seat heating is needed, only the new request parameters need to be added according to the established format, without significantly modifying existing code.

[0085] As an optional implementation, the request parameters include a request type and a request ID, whereby the request ID indicates the number of communication requests. After the request message is sent to the responding end via the first communication channel provided by the responding end, the method further includes the following steps:

[0086] Step S21: Determine the flag value of the request type in the request parameters, where the flag value is used to indicate whether the response end needs to provide a processing result.

[0087] When the request packet is constructed and ready to be sent, the request-type field in the request parameters needs to be checked first to determine the flag value of the request type. The value of this field (i.e. the flag value of the request type) is used to indicate whether the response end needs to provide feedback on the processing result.

[0088] For example, according to the SAUP protocol, the request-type field has two optional values: SendOnly (first flag value) and ResponseRequire (second flag value). The former indicates that only a notification is sent and no response is required from the responding end; the latter indicates that a communication request is initiated and a response from the responding end is required.

[0089] Different business scenarios determine which request type to use. For operations with low real-time requirements or no need for immediate feedback, such as logging or status updates, the SendOnly type can be used to simplify the process; while for interactive operations requiring immediate response, such as control commands or query requests, the ResponseRequire type should be chosen to ensure successful completion. For example, in a smart cockpit system, if a notification to update vehicle status is sent from Android to Unity, immediate confirmation from Unity may not be necessary; however, if querying the status of a specific function, the system must wait for Unity to return the specific result.

[0090] By explicitly distinguishing request types using flag values, communication efficiency can be optimized without affecting core business logic. For operations that don't require waiting for a response, directly ending the process can reduce unnecessary resource consumption and improve overall performance. At the same time, this approach also increases system flexibility, allowing developers to flexibly adjust request types according to actual needs and adapt to application requirements in different scenarios.

[0091] Step S22: If the request type flag value is the first flag value, then it is determined that no response is needed and the process ends.

[0092] When the request type is determined to be SendOnly (i.e., the first flag value), it indicates that this request is a one-way notification, and no feedback is needed from the responding end. In this case, once the request message is successfully sent to the responding end, the communication can be considered complete, and the client can immediately end the relevant processing flow. Using the SendOnly request type can reduce system load, especially in high-concurrency scenarios, reducing server-side pressure. 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 timer to turn off the lights via a mobile app, the user only needs to synchronize the setting with the home gateway, without waiting for the actual execution result, because even without 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, then it is determined that the response end needs to provide feedback on the processing result and a sub-thread is started to receive the processing result; the corresponding business operation is executed according to the response ID carried in the processing result.

[0095] If the request type is marked as ResponseRequire (i.e., the second flag 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 from the responding end. In order not to affect the operation of the main thread, a child thread is usually started to receive and process these results. For example, in an online game scenario, when a player sends a request to buy an item, the client not only needs to send the purchase command to the server but also needs to wait for the server to confirm whether the transaction was successful and update the local state according to the returned result.

[0096] Optionally, to avoid indefinite waiting, a reasonable timeout period (e.g., 5000 milliseconds) can be set. If no response is received within the specified time, the communication is considered a failure, and corresponding measures are taken, such as resending the request or displaying a failure message to the user. If the child thread receives the processing result within the specified time, it matches the corresponding request based on the response ID carried in the result and executes the corresponding business operation, such as updating the UI interface or modifying database records.

[0097] This application uses a sub-thread to handle requests that require a response. This asynchronous processing method not only improves the system's response speed but also enhances its stability. Even if a response is not received in a timely manner under certain circumstances, the system can respond appropriately through a timeout mechanism to avoid getting stuck in 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 be accurately matched, thereby maintaining data consistency and integrity.

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

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

[0100] After the requesting end sends a request message, the responding end needs to receive this message through a specific response function. This step ensures that the request information can be accurately captured by the responding end and enter the processing flow. For example, in a 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 a timely manner and be ready to proceed with the next step of parsing and processing.

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

[0102] By using dedicated response functions to receive request messages, it is ensured that each request is effectively captured, avoiding information loss due to network fluctuations or other factors. Furthermore, this design enhances the system's flexibility and scalability; even if new request types are added or existing communication protocols change in the future, only the response functions need to be updated to accommodate the changes, without requiring large-scale modifications to other modules.

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

[0104] After receiving the request message, the next step for the responding end is to parse it and extract key request parameters, including the request path, request body type, and request body content. These parameters provide necessary guidance for subsequent processing. For example, if the request path is CarModel / Control / Window / ChangeWindowState, it indicates that this is a request regarding a change in 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 transformed into the data format required by the specific business logic, simplifying the processing. Clear parameter definitions and formatting rules reduce the possibility of misunderstanding and improve processing accuracy. At the same time, this standardized parsing process also facilitates future maintenance and upgrades; any adjustments to the request parameter structure can be implemented centrally in this step without affecting the functionality of other parts.

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

[0107] After parsing the request parameters, the response end assigns the task to the corresponding processing unit based on the request path. This process can be accomplished 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 has its own independent processing logic. For example, a request with the path CarModel / Control / Window / ChangeWindowState will be dispatched to the processing unit responsible for vehicle model control, which focuses on handling all requests related to the window state.

[0108] In this application, a task distribution mechanism based on request paths enables fine-grained management of request processing, ensuring that each request is executed by the most suitable processing unit. This approach not only improves processing efficiency but also enhances the modularity of the system, resulting in lower coupling between different functions and facilitating independent 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 existing functions.

[0109] Step S34: The processing unit processes the request body type and request body content, obtains and stores the processing result, wherein the status code in the processing result is used to indicate whether the processing was successful.

[0110] After receiving the request message, the processing unit begins processing the request body type and content. Depending on 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 calls to external services. Ultimately, the processing unit will generate a processing result including a status code and store it for later use. A status code of 1 indicates successful processing, and a status code of 0 indicates failure. 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 success status code (such as 1) along with the specific query result.

[0111] In this application, requests are processed by a processing unit, ensuring that each request receives an appropriate response. The presence of status codes provides the requesting end with clear feedback, enabling it to take further action based on the processing status. Furthermore, the storage of processing results provides fundamental support for functions such as logging and audit trails, contributing to improved system transparency and traceability. For example, in a smart cockpit system, users can view the processing results to understand the actual execution of each operation, thereby gaining a better understanding of the vehicle's status.

[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 parameters.

[0114] After the responding end finishes processing the request, it first needs to check the `request-type` field in the request parameters to determine whether the request requires a response. The value of this field (i.e., the flag value) indicates the type of request and determines the direction of subsequent processes. For example, in a smart cockpit system, if Android sends a request to Unity to query the vehicle's current speed, the request might be marked as `ResponseRequire`, indicating that Unity needs to return the specific query result.

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

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

[0117] Step S43: If the tag value of the request type is the second tag value, then call the second communication channel provided by the requesting end, and send the processing result carrying the response ID back to the requesting end based on the response target. 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 flag 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 from the response end. To achieve this process, the response end will call the second communication channel provided by the requesting end and send the processing result, which includes the response ID, back to the requesting end.

[0119] The response end constructs a processing result including a response ID to ensure that each processing result accurately corresponds to a specific request. The response ID is generated by the response end and automatically increments from 1 to guarantee uniqueness.

[0120] This application uses response IDs to identify each processing result, ensuring that each request and its corresponding processing result are accurately matched, thereby maintaining data consistency and integrity. For example, in a smart cockpit system, users can quickly send status update requests with a simple click, while for important control commands, the system ensures that they are processed correctly and that results are provided in a timely manner, offering users a smoother and more reliable user experience.

[0121] This application uses the example of Android sending a communication request to Unity to illustrate the communication process, such as... Figure 3 As shown, the steps include the following.

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

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

[0124] Step 3: On the Android side, the request-type field is checked. If it is SendOnly, the Android process ends directly. If it is ResponseRequire, a background thread needs to be started to wait for the Unity side to return the processing result. If no result is received from the Unity side after a certain period of time, the communication request is considered to have timed out. The default timeout period is 5000ms. After the timeout, the next step can be performed according to the business logic, choosing to re-request or directly determine that the request failed and display a prompt.

[0125] Step 4: After receiving the request message, Unity parses it into a processable data format. Based on the value of the path field, it dispatches the data to different scripts. The scripts read the value in content-data, obtain the data transmitted from the Android side, process the data, and cache the processing results for later use.

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

[0127] Step 6: The Android client receives the processing result returned by the Unity client. It can determine which request the processing result is based on the response ID, and then execute the next step of logic based on the processing result. This completes the entire process.

[0128] This application standardizes and unifies the communication between the requesting and responding ends by defining a standard communication process and data protocol. This reduces the need for function writing, keeps the code clear and concise, facilitates code maintenance, and improves development efficiency. Furthermore, the unified data format enhances scalability, breaks free from the limitation of related technologies that only allow unidirectional message sending, and enables bidirectional communication between the requesting and responding ends.

[0129] Based on the same technical concept, this application provides a communication device between a requesting end and a responding end, applied to the requesting end, such as... Figure 4 As shown, the device includes:

[0130] The first acquisition module 401 is used to acquire the unified standard communication process and communication data protocol between the client and the responder. The standard communication process encapsulates request functions and response functions.

[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 the response end, wherein the response 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 for:

[0133] Construct a request data packet containing request parameters, wherein the request parameters include the request target indicating the response end;

[0134] The request function is called, passing in a request data packet and converting the request data packet into a request message, wherein the request message is in the data format specified by the communication data protocol;

[0135] Based on the requested objective, the request message is sent to the responding end via the first communication channel provided by the responding end.

[0136] Optionally, the request parameters include a request type and a request ID, whereby the request ID indicates the number of communication requests. The device is also used to:

[0137] Determine the flag value for the request type in the request parameters, where the flag value indicates whether the response end needs to provide a processing result;

[0138] If the request type is marked with the first mark value, then it is determined that no response is needed and the process ends.

[0139] If the request type is marked with the second mark value, it is determined that the response end needs to provide a processing result and a sub-thread is started to receive the processing result; the corresponding business operation is executed according to the response ID carried in the processing result.

[0140] Based on the same technical concept, this application provides a communication device between a requesting end and a responding end, applied to the responding end, the device comprising:

[0141] The second acquisition module is used to acquire the unified standard communication process and communication data protocol between the client and the requesting client. The standard communication process encapsulates response functions and request functions.

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

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

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

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

[0146] The request message is dispatched to at least one processing unit according to the request path;

[0147] The processing unit processes the request body type and request body content, obtains and stores the processing result, and the status code in the processing result is used to indicate whether the processing was successful.

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

[0149] Determine the request type flag value in the request parameters;

[0150] If the request type's tag value is the first tag value, then the process ends;

[0151] If the request type is marked with the second mark value, the second communication channel provided by the requesting end is invoked, and the processing result carrying the response ID is fed back to the requesting end based on the response target. 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, this 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] Memory 503 is used to store computer programs.

[0154] In one embodiment of this application, the processor 501, when executing the program stored in the memory 503, implements the communication method between the requesting end and the responding end provided in any of the foregoing method embodiments.

[0155] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the communication method between a requester and a response as provided in any of the foregoing method embodiments.

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

[0157] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0158] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0159] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A communication method between a requesting end and a responding end, characterized in that, Applied to the requesting end, the method includes: A unified standard communication process and communication data protocol are obtained between the acquiring and responding ends. The standard communication process encapsulates request functions and response functions. The communication data protocol predefines request and response parts. The request part includes request type, request target, request ID, request path, request body type, and request body content. The request ID refers to the identification information of this communication request, and the request ID is different for each communication request. The response part includes response ID, response target, status code, response body type, and response body content. The response ID refers to the identification information of this communication processing result, and the response ID is different for each communication processing result. The standard communication process is executed based on the request function and the communication data protocol to complete the communication with the responding end. The standard communication process means that all communication requests follow a unified pattern. The execution of the standard communication process based on the request function and the communication data protocol includes: Construct a request data packet containing request parameters according to the request portion of the communication data protocol, wherein the request parameters conform to the requirements of the request portion; The request function is called to standardize the request data packet according to the communication data protocol, generate a request message, and send the request message to the response end. The response end then parses the request parameters in the request message according to the requirements of the request part and assigns the task to the corresponding processing unit according to the request path to obtain the processing result. If a new control function needs to be added, a new processing unit is added. Each processing unit has independent processing logic. If a new or modified function request is detected, the request data packet is adjusted according to the requirements of the request section. If the processing result sent by the response end is received, the processing result is parsed according to the requirements of the response part of 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: Construct a request data packet containing request parameters, wherein the request parameters include a request target indicating the responding end; The request function is invoked, passing in the request data packet and converting the request data packet into a request message, wherein the request message is in the data format specified by the communication data protocol; Based on the requested target, the request message is sent to the response end by invoking the first communication channel provided by the response end.

3. The method according to claim 2, characterized in that, The request parameters also include a request type and a request ID. After sending the request message to the response end via the first communication channel provided by the response end, the method further includes: Determine the flag value of the request type in the request parameters, wherein the flag value is used to indicate whether the response end needs to provide a processing result; If the flag value of the request type is the first flag value, then it is determined that no processing result is needed from the responding end and the process ends; If the flag value of the request type is the second flag value, then it is determined that the response end needs to provide a processing result and a sub-thread is started to receive the processing result; the corresponding business operation is executed according to the response ID carried in the processing result.

4. A communication method between a requesting end and a responding end, characterized in that, Applied to the response end, the method includes: A unified standard communication process and communication data protocol are obtained between the requesting end and the receiving end. The standard communication process encapsulates response functions and request functions. The communication data protocol predefines a request part and a response part. The request part includes a request type, a request target, a request ID, a request path, a request body type, and a request body content. The request ID refers to the identification information of this communication request, and the request ID is different for each communication request. The communication data protocol predefines a response part, which includes a response ID, a response target, a status code, a response body type, and a response body content. The response ID refers to the identification information of this communication processing result, and the response ID is different for each communication processing result. The standard communication process is executed based on the response function and the communication data protocol to complete the communication with the requesting end. The standard communication process means that all communication requests follow a unified pattern. The execution of the standard communication process based on the response function and the communication data protocol includes: Call the response function to receive the request message sent by the requesting end; The request parameters in the request message are parsed according to the request portion of the communication data protocol, wherein the request parameters conform to the requirements of the request portion; The task is assigned to the corresponding processing unit according to the request path in the request parameters. If a new control function needs to be added, a new processing unit is added. Each processing unit has independent processing logic. The processing unit processes the request body type and the request body content to obtain and store the processing result; If the request message contains a request for adding or modifying a function, then the corresponding processing unit is added or modified. The processing result is encapsulated according to the requirements of the response portion of the communication data protocol and sent to the requesting end, so that the requesting end can parse the processing result according to the requirements of the response portion.

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: Call the response function to receive the request message sent by the requesting end; Parse the request parameters in the request message, wherein the request parameters include the request path, request body type, and request body content; The request message is dispatched to at least one processing unit according to the request path; The processing unit processes the request body type and the request body content to obtain and store the processing result, wherein the status code in the processing result is used to indicate whether the processing was successful.

6. The method according to claim 5, characterized in that, After obtaining and storing the processing result, the method further includes: Determine the flag value for the request type in the request parameters; If the flag value of the request type is the first flag value, then the process ends; If the tag value of the request type is the second tag value, then the second communication channel provided by the requesting end is invoked, and the processing result carrying the response ID is fed back to the requesting end based on the response target. 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 requesting end and a responding end, characterized in that, Applied to the requesting end, the device includes: The first acquisition module is used to acquire a unified standard communication process and communication data protocol between the client and the responding client. The standard communication process encapsulates a request function and a response function. The communication data protocol predefines a request part and a response part. The request part includes a request type, a request target, a request ID, a request path, a request body type, and a request body content. The request ID refers to the identification information of this communication request, and the request ID is different for each communication request. The response part includes a response ID, a response target, a status code, a response body type, and a response body content. The response ID refers to the identification information of this communication processing result, and the response ID is different for each communication processing result. 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 response end, wherein the standard communication process means that all communication requests follow a unified pattern; The execution of the standard communication process based on the request function and the communication data protocol includes: Construct a request data packet containing request parameters according to the request portion of the communication data protocol, wherein the request parameters conform to the requirements of the request portion; The request function is called to standardize the request data packet according to the communication data protocol, generate a request message, and send the request message to the response end. The response end then parses the request parameters in the request message according to the requirements of the request part and assigns the task to the corresponding processing unit according to the request path to obtain the processing result. If a new control function needs to be added, a new processing unit is added. Each processing unit has independent processing logic. If a new or modified function request is detected, the request data packet is adjusted according to the requirements of the request section. If the processing result sent by the response end is received, the processing result is parsed according to the requirements of the response part of the communication data protocol.

8. A communication device between a requesting end and a responding end, characterized in that, Applied to the response end, the device includes: The second acquisition module is used to acquire a unified standard communication process and communication data protocol between the client and the requesting client. The standard communication process encapsulates a response function and a request function. The communication data protocol predefines a request part and a response part. The request part includes a request type, a request target, a request ID, a request path, a request body type, and a request body content. The request ID refers to the identification information of this communication request, and the request ID is different for each communication request. The communication data protocol predefines a response part, which includes a response ID, a response target, a status code, a response body type, and a response body content. The response ID refers to the identification information of this communication processing result, and the response ID is different for each communication processing result. 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 requesting end, wherein the standard communication process means that all communication requests follow a unified pattern; The second execution module is used for: Call the response function to receive the request message sent by the requesting end; The request parameters in the request message are parsed according to the request portion of the communication data protocol, wherein the request parameters conform to the requirements of the request portion; The task is assigned to the corresponding processing unit according to the request path in the request parameters. If a new control function needs to be added, a new processing unit is added. Each processing unit has independent processing logic. The processing unit processes the request body type and the request body content to obtain and store the processing result; If the request message contains a request for adding or modifying a function, then the corresponding processing unit is added or modified. The processing result is encapsulated according to the requirements of the response portion of the communication data protocol and sent to the requesting end, so that the requesting end can parse the processing result according to the requirements of the response portion.

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, when executing a program stored in memory, implements the method of any one of claims 1-3 or 4-6.

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

Images