Response processing method, device and equipment

Abstract

The invention discloses a response processing method, device and equipment, and relates to the technical field of communication, and the method comprises the steps that an intermediate processing layer deployed between an application layer and an underlying service obtains response data which does not contain a session identifier and is broadcasted by the underlying service, reads a to-be-matched request list, and sends the to-be-matched request list to the application layer; according to the method and the device, the response data is acquired, the target request matched with the response data is screened out from the to-be-matched request list, and the request response of the target request is performed according to the response data, so that the response data without the session identifier is matched with the target request by deploying the intermediate processing layer between the application layer and the underlying service.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a response processing method, apparatus and device. Background Technology

[0002] In the distributed system architecture of terminal devices, communication between the application layer and underlying services, as well as between modules, is the core link supporting the implementation of functions. As the functions of terminal devices continue to be enriched and the demand for multi-module collaboration increases, the application layer and underlying services need to frequently initiate data interaction requests.

[0003] To accommodate multi-module communication and simplify implementation, a broadcast response mechanism is often used between the application layer and the underlying services. This means that after receiving a request, the underlying service does not return a response point-to-point to a specific request, but instead sends the response data in a broadcast manner. In this case, the communication protocol often does not embed a session identifier in the response data, resulting in broadcast communication without a session identifier. However, as the functions of terminal devices become increasingly rich, multiple concurrent requests have become the norm. Due to the lack of a unique identifier in the response data, the application layer cannot accurately associate the broadcast response data with the corresponding request. Summary of the Invention

[0004] In view of the above problems, this application provides a response processing method, apparatus, and device to overcome or at least partially solve the above problems, the technical solution of which is as follows: A response processing method is applied to an intermediate processing layer between an application layer and an underlying service. The method includes: obtaining response data broadcast by the underlying service; the response data does not contain a session identifier; reading a list of requests to be matched, and filtering out a target request that matches the response data from the list of requests to be matched; and responding to the target request based on the response data.

[0005] The response processing method provided in this application deploys an intermediate processing layer between the application layer and the underlying service. This intermediate processing layer obtains response data broadcast by the underlying service that does not contain a session identifier and determines the target request that matches the response data. Thus, by deploying the intermediate processing layer, the matching of the response data broadcast by the underlying service with the request submitted by the application layer is achieved. Even when the response data does not contain a session identifier, a one-to-one correspondence between the response data and the target request is established through matching the response data with the request to be matched. Specifically, after obtaining the response data broadcast by the underlying service that does not contain a session identifier, the intermediate processing layer first reads the list of requests to be matched, and then filters out the target request that matches the response data from the list. This management of the requests to be matched by maintaining the list improves the efficiency of target request filtering and avoids filtering from all global requests, which would affect filtering efficiency. After filtering out the target request that matches the response data, the intermediate processing layer responds to the target request based on the response data. This improves the matching accuracy while achieving the matching of response data and target requests, thereby enhancing the user's perception of the request and the matching response data.

[0006] Optionally, the step of filtering out target requests that match the response data from the list of requests to be matched includes: extracting response features from the response data and extracting request features from candidate requests to be matched in the list of requests to be matched; calculating feature similarity based on the request features and the response features; determining the candidate request to be matched as the target request if the feature similarity is greater than a similarity threshold; and obtaining the next candidate request to be matched in the list of requests to be matched if the feature similarity is less than or equal to the similarity threshold, and returning to perform the operation of extracting request features from candidate requests to be matched in the list of requests to be matched.

[0007] In this optional implementation, during the process of filtering target requests that match response data, the feature similarity between response features and request features is calculated, and candidate requests to be matched with a feature similarity greater than a similarity threshold are identified as target requests. In this way, the target requests are identified by feature similarity, thereby improving the accuracy of the identified target requests.

[0008] Optionally, calculating feature similarity based on the request features and the response features includes: comparing whether the key response features in the response features are consistent with the key request features in the request features; if yes, calculating feature similarity based on the baseline response features in the response features and the baseline request features in the request features; if no, obtaining the next candidate request to be matched in the list of requests to be matched, and returning to perform the operation of extracting the request features of the candidate requests to be matched in the list of requests to be matched.

[0009] In this optional implementation, during the calculation of feature similarity, the key response feature is first compared with the key request feature to see if they are consistent. If they are consistent, feature similarity is then calculated based on the baseline response feature and the baseline request feature. In this way, feature similarity calculation is not required when the key response feature and the key request feature are inconsistent, thus avoiding the waste of computing resources caused by performing feature similarity calculation when there are obvious differences between the key response feature and the key request feature. Feature similarity is only calculated based on the baseline response feature and the baseline request feature when they are consistent, thus achieving accurate feature similarity calculation while saving computing resources.

[0010] Optionally, before the operation of obtaining the response data broadcast by the underlying service is executed, the method further includes: obtaining the pending requests in the serialized request queue; sending the pending requests to the underlying service for request execution; and determining the pending requests as matching requests and updating the matching request list.

[0011] In this optional implementation, the requests to be executed are managed in the form of a serialized request queue. During the execution of the requests, the requests are executed through the serialized request queue, thereby ensuring the order of the response data and improving the efficiency of matching the target requests.

[0012] Optionally, after sending the request to be executed to the underlying service for request execution, and determining the request to be executed as a matching request and updating it to the matching request list for execution, the method further includes: obtaining historical execution requests corresponding to the request type of the matching request; calculating the predicted response time of the matching request based on the request response time of the historical execution requests, and performing countdown processing based on the predicted response time; if the matching request does not match response data after the countdown processing, performing a request response for the matching request based on empty response data.

[0013] In this optional implementation, after updating the pending request to the list of pending requests, a countdown is performed based on the predicted response time. If no response data is matched after the countdown ends, the pending request is responded to based on empty response data. This avoids the user's perception of the submitted pending request being affected by the fact that the user has not received feedback on the pending request for a long time.

[0014] Optionally, the step of calculating the predicted response time of the request to be matched based on the request response time of the historical execution requests includes: calculating the time average of the request response times, and calculating the product of the time average and a preset parameter as a candidate response time; detecting whether the candidate response time is within a valid time interval; if so, determining the candidate response time as the predicted response time; if not, taking the interval boundary corresponding to the candidate response time in the valid time interval as the predicted response time.

[0015] In this optional implementation, during the calculation of the predicted response time of the request to be matched, a candidate response time is first calculated using preset parameters and the average time of the historical execution response times corresponding to the request type of the request to be matched. Then, the candidate response time is calculated in conjunction with the historical request response times corresponding to that request type, making the candidate response time more closely resemble the actual response time and improving the effectiveness and accuracy of the calculated candidate response time. Furthermore, after calculating the candidate response time, it can be further corrected based on the effective time interval to avoid the candidate response time being too short to actually receive the response data, and also to avoid the response time being too long to affect the user's perception, thus improving the accuracy and effectiveness of the determined predicted response time.

[0016] Optionally, the target request is converted to a coroutine suspended state before being written into the list of requests to be matched; the execution of the coroutine corresponding to the target request is resumed after the response data matches the target request.

[0017] This optional implementation converts the target request into a coroutine suspension state before it is written into the list of requests to be matched, and resumes the execution of the coroutine corresponding to the target request after the response data matches the target request. It does not occupy thread resources while waiting for response data, thus achieving efficient serialization processing.

[0018] Optionally, the method further includes: caching the response data; if a target request to be executed is obtained, calculating a target feature similarity based on the target request features of the target request to be executed and the response features of the response data; if the target feature similarity is greater than a similarity threshold, performing a request response for the target request to be executed based on the response data.

[0019] This optional implementation caches the response data after it is obtained. If the feature similarity between the target request feature and the response feature of the target request to be executed is greater than a similarity threshold, the request response to the target request to be executed is performed based on the response data. By caching and reusing the response data, the number of requests is reduced and the system load is lowered.

[0020] A response processing apparatus, operating in an intermediate processing layer between the application layer and underlying services, the apparatus comprising: The acquisition module is used to acquire response data broadcast by the underlying service; the response data does not contain a session identifier. The filtering module is used to read the list of requests to be matched and filter out the target requests that match the response data from the list of requests to be matched. The response module is used to respond to the target request based on the response data.

[0021] Optionally, the filtering module is specifically used to: extract response features from the response data and extract request features from the candidate requests to be matched in the list of requests to be matched; calculate feature similarity based on the request features and the response features; if the feature similarity is greater than a similarity threshold, determine the candidate request to be matched as the target request; if the feature similarity is less than or equal to the similarity threshold, obtain the next candidate request to be matched in the list of requests to be matched, and return to perform the operation of extracting request features from the candidate requests to be matched in the list of requests to be matched.

[0022] Optionally, when calculating feature similarity based on the request features and the response features, the filtering module specifically performs the following: comparing whether the key response features in the response features are consistent with the key request features in the request features; if so, calculating feature similarity based on the baseline response features in the response features and the baseline request features in the request features; if not, obtaining the next candidate request to be matched in the list of requests to be matched, and returning to perform the operation of extracting the request features of the candidate requests to be matched in the list of requests to be matched.

[0023] Optionally, the apparatus further includes a request execution module, which is specifically used to: obtain requests to be executed in a serialized request queue; send the requests to be executed to the underlying service for request execution; and determine the requests to be executed as requests to be matched and update the list of requests to be matched.

[0024] Optionally, the device further includes a countdown module, which is specifically used to: obtain historical execution requests corresponding to the request type of the request to be matched; calculate the predicted response time of the request to be matched based on the request response time of the historical execution requests, and perform countdown processing based on the predicted response time; if the request to be matched does not match response data after the countdown processing is completed, perform a request response for the request to be matched based on empty response data.

[0025] Optionally, when the countdown module calculates the predicted response time of the request to be matched based on the request response time of the historical execution requests, it specifically performs the following: calculates the time average of the request response times, and calculates the product of the time average and a preset parameter as a candidate response time; detects whether the candidate response time is within a valid time interval; if so, determines the candidate response time as the predicted response time; if not, takes the interval boundary corresponding to the candidate response time in the valid time interval as the predicted response time.

[0026] Optionally, the target request is converted to a coroutine suspended state before being written into the list of requests to be matched; the execution of the coroutine corresponding to the target request is resumed after the response data matches the target request.

[0027] Optionally, the device further includes a caching module, which is specifically used for: caching the response data; if a target request to be executed is obtained, calculating a target feature similarity based on the target request features of the target request to be executed and the response features of the response data; and if the target feature similarity is greater than a similarity threshold, performing a request response for the target request to be executed based on the response data.

[0028] A vehicle comprising the response processing device as described above.

[0029] An electronic device includes: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described response processing methods when executing the computer program.

[0030] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the above-described response processing methods.

[0031] A computer program product includes a computer program that, when executed by a processor, implements the steps of any of the above-described response processing methods.

[0032] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0033] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a schematic diagram of a response processing system provided in an embodiment of this application; Figure 2 This is an illustrative flow diagram of a response processing method provided in an embodiment of this application. Figure 1 ; Figure 3 This is a schematic diagram of a response processing method provided in an embodiment of this application; Figure 4 This is a schematic flowchart illustrating a countdown processing procedure provided in an embodiment of this application; Figure 5 This is a schematic flowchart illustrating a target request filtering process provided in an embodiment of this application; Figure 6 This is an illustrative flow diagram of a response processing method provided in an embodiment of this application. Figure 2 ; Figure 7 This is a schematic structural diagram of a response processing device provided in an embodiment of this application; Figure 8 This is a structural schematic diagram of a vehicle provided in an embodiment of this application. Detailed Implementation

[0034] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0035] In distributed system architectures, a broadcast response mechanism is often used between the application layer and underlying services. For example, in a smart cockpit system architecture, in-vehicle applications need to frequently interact with underlying services to realize the rich functions of the smart cockpit. Currently, data interaction between in-vehicle applications and underlying services is often implemented using in-vehicle communication protocols such as SOME / IP (Scalable service-oriented middleware over IP), AIDL (Android Interface Definition Language), and Binder IPC (Binder Inter-Process Communication). However, these in-vehicle communication protocols share a common characteristic: response data is returned via broadcast, lacking a session identifier to associate requests and responses. This leads to the inability to determine which request's response data belongs to in scenarios with multiple concurrent requests, resulting in a series of problems such as data confusion, UI (User Interface) state errors, and a degraded user experience.

[0036] To address this issue, the response processing method provided in this embodiment solves the technical problem of being unable to determine the request corresponding to the response data under a communication protocol without a session identifier. An intermediate processing layer is deployed between the application layer and the underlying service to execute requests initiated by the application layer and receive response data broadcast by the underlying service. The intermediate processing layer matches the response data with the request. Thus, even when the response data does not contain a session identifier during data interaction between the application layer and the underlying service based on a communication protocol without a session identifier, matching the response data with the request is achieved. After obtaining the response data broadcast by the underlying service without a session identifier, the intermediate processing layer filters out the target request that matches the response data from the list of requests to be matched, and then responds to the target request based on the response data. This achieves accurate matching of response data and request. Based on the matching of response data and request, and by responding to the target request based on the response data, the user's perception of the response status of the target request is improved.

[0037] like Figure 1 As shown, Figure 1 This is a schematic diagram of a response processing system provided in an embodiment of this application. The response processing system includes: Application layer 101, underlying service 102, and intermediate processing layer 103 deployed between application layer 101 and underlying service 102; The application layer 101 is used to submit requests to be executed. For example, users submit requests for accessing photo albums, navigation, and / or multimedia through the application layer 101. The underlying service 102 is used to generate response data for the request to be executed; for example, the underlying service 102 includes DVR (Digital Video Recorder) service, navigation sub-service and / or multimedia sub-service; in addition, the underlying service 102 may also include 360-degree surround view service and / or driver assistance service, which are not limited in this embodiment.

[0038] The intermediate processing layer 103 is used to obtain the pending requests submitted by the application layer 101, and to execute the pending requests in a serialized manner. After the request is executed, the pending requests are stored as matching requests in the matching request list. In addition, the intermediate processing layer 301 is also used to obtain the response data broadcast by the underlying service 102 that does not contain a session identifier. After filtering out the target requests that match the response data from the matching request list, the target request is responded to based on the response data.

[0039] In addition, the response processing system may also include a communication protocol layer 104 and a response data broadcast layer 105. During the process of request execution, the intermediate processing layer 103 first sends the request to be executed to the communication protocol layer 104. The communication protocol layer 104 sends the request to be executed to the underlying service 102 according to the communication protocol SOME / IP interface, AIDL interface and / or Binder IPC interface. After generating response data, the underlying service 102 sends the response data to the response data broadcast layer 105 for data broadcasting.

[0040] It should be noted that the intermediate processing layer 103 may include a matching algorithm 103-1 for filtering target requests that match the response data; in addition, the intermediate processing layer 103 may also include a request queue manager 103-2 for managing the serialized request queue; it may also include a countdown processor 103-3 for performing corresponding countdown processing after executing the request to be executed; and it may also include a statistical analyzer 103-4 for performing statistics on the predicted response time required by the countdown processor 103-3.

[0041] In the specific execution process, after the intermediate processing layer 103 receives the pending request submitted by the application layer 101, it first manages the pending request in a serialized manner through the request queue manager 103-2. After detecting that the pending request has been executed, it calculates the predicted response time of the pending request through the statistical analyzer 103-4, and then performs countdown processing on the pending request according to the predicted response time through the countdown processor 103-3. After receiving the response data generated by the underlying service 102 and broadcast through the response data broadcast layer 105, the intermediate processing layer 103 filters the target request that matches the response data in the list of pending requests through the matching algorithm 103-1. After obtaining the target request, it sends a request response to the application layer 101 based on the response data.

[0042] like Figure 2 As shown, Figure 2 This is a schematic flowchart illustrating a response processing method provided in an embodiment of this application. The method can be applied to an intermediate processing layer between the application layer and the underlying service. The method includes: Step 201: Obtain the response data broadcast by the underlying service.

[0043] In practice, the intermediate processing layer between the application layer and the underlying service obtains the response data broadcast by the underlying service that does not contain a session identifier.

[0044] In this embodiment, an intermediate processing layer can be deployed between the application layer and the underlying services to match response data with requests. This intermediate processing layer can be deployed on terminal devices, such as in-vehicle terminals, mobile phones, or other mobile terminal devices. It is used to receive pending requests submitted by users through the application layer of the terminal device, execute these requests, and also to obtain response data broadcast by the underlying services that does not contain a session identifier, and match the response data with the requests. The pending requests in this embodiment include DVR requests, navigation requests, and / or multimedia requests submitted based on the application layer; furthermore, the pending requests can also be other requests submitted based on the application layer, which are not limited in this embodiment.

[0045] The response data in this embodiment includes response data generated by the underlying service during data interaction based on the communication protocol, which does not contain a session identifier. For example, in a smart cockpit system, the response data includes response data generated by the underlying service during data interaction based on the vehicle communication protocol, which does not contain a session identifier. Optionally, the response data generated by the underlying service does not contain a session identifier. The session identifier in this embodiment includes an identifier that characterizes the uniqueness of the request and the one-to-one correspondence between the request and the response data. Session identifiers include, for example, session identifiers (Session ID, SessionIdentifier), request identifiers (Request ID, Request Identifier), and / or tokens.

[0046] In practice, after receiving the pending requests sent by the application layer, the intermediate processing layer adds the requests to a serialized request queue. This serialized request queue ensures that concurrently arriving requests are processed sequentially, preventing response chaos. Furthermore, to avoid static conditions, atomic operation flags can be used to control the queue processing state. In addition, to improve the ease of managing the serialized request queue, a request identifier can be generated for each pending request to characterize its uniqueness.

[0047] During the actual execution process, the pending requests sent by the application layer are obtained, a request identifier for the pending requests is generated, and the pending requests are added to the serialized request queue based on the request identifier.

[0048] After adding the pending requests to the serialization request queue, the pending requests in the serialization request queue are executed. In one optional implementation of this embodiment, during the execution of the pending requests in the serialization request queue, the pending requests in the serialization request queue are first obtained, and then the pending requests are sent to the underlying service for execution. In addition, in order to improve the subsequent filtering of target requests, the pending requests can be identified as matching requests and updated to the matching request list.

[0049] In addition to identifying pending requests as matching requests and updating the matching request list, after sending the pending requests to the underlying service for execution, the request status of pending requests in the serialized request queue can be updated to a matching status. During the execution process, atomic boolean update operations can be used to ensure the atomicity of the serialized request queue when updating the request status of pending requests.

[0050] For example, after sending a request to be executed to the underlying service, the request status of the request in the serialized request queue is updated to a matching status using the CAS (Compare-And-Swap) operation of Atomic Boolean.

[0051] It should be noted that during the process of retrieving pending requests from the serialized request queue, the first pending request in the queue can be retrieved. It should also be noted that, for effective response data retrieval, after retrieving the pending request, a response callback can be registered with the response detector to send the response data back to the intermediate processing layer upon detection.

[0052] For example, such as Figure 3 As shown, after receiving the pending request sent by the application layer, the intermediate processing layer first generates a request identifier for the pending request and writes it into a serialized request queue based on the request identifier. During the execution of pending requests in the serialized request queue, the intermediate processing layer first retrieves the pending requests from the queue. To obtain response data, it also registers a response callback with the response detector and then sends the pending request to the request executor. The request executor sends a processing request to the underlying service based on the communication protocol. The underlying service executes the request based on the received processing request and broadcasts the response data. After detecting the response data, the response detector sends the response data to the intermediate processing layer. The intermediate processing layer filters out target requests whose response data matches and then sends the target request's response data back to the application layer. For pending requests that do not find a matching response, they simply wait for a match.

[0053] It should be noted that the above describes the process of adding a request to be executed to the serialization request queue. For multiple requests to be executed, all requests can be added to the serialization request queue. The specific execution process is similar to the above process. Please refer to the relevant content above. This embodiment does not limit it here.

[0054] In practical implementation, after sending a request to be executed to the underlying service, data transmission and response data generation by the underlying service take time. To avoid occupying thread resources while waiting for a matching request (i.e., a request in the matching state), this embodiment updates the request status of the request to be executed to the matching state or updates the request to the list of matching requests, and then converts the request to be executed into a coroutine suspended state. This way, thread resources are not occupied while waiting for a response, allowing thread resources to be used for executing other requests or processing other tasks, achieving efficient serialization. Furthermore, after obtaining the response data matching the request to be executed, the execution of the coroutine corresponding to the request to be executed can be resumed to achieve a response to the request.

[0055] In practical implementation, to avoid situations where pending requests or requests in a pending-matching state remain unmatched for extended periods, causing users who submitted such requests to be in a prolonged waiting state and unable to perceive the request result, this embodiment, after sending the pending-execution request to the underlying service for execution, uses a pending-matching request as an example for explanation. For pending requests or requests in a pending-matching state, a countdown process is performed. If no response data is matched by the end of the countdown, the pending-matching request is responded to based on empty response data, thereby improving the user's perception of the response result for the pending-matching request.

[0056] In the process of counting down to matching requests, in order to improve the effectiveness of the countdown and avoid the inability to respond effectively due to random determination of the countdown time, the predicted response time of the request to be matched can be calculated based on the historical request response time corresponding to the request type of the request to be matched. The countdown is then performed based on the predicted response time. In this way, the predicted response time is calculated in combination with the historical request time corresponding to the request type, which improves the effectiveness of the countdown and avoids the waiting waste caused by a fixed countdown time or the situation of the countdown ending prematurely.

[0057] Based on this, in one optional implementation of this embodiment, during the countdown processing of the request to be matched, the historical execution request corresponding to the request type of the request to be matched is first obtained, and then the predicted response time of the request to be matched is calculated based on the request response time of the historical execution request, and the countdown processing is performed based on the predicted response time; if the request to be matched does not match the response data after the countdown processing ends, the request response of the request to be matched is performed based on the empty response data.

[0058] In the process of calculating the predicted response time of the request to be matched based on the historical request response time, the average time of the request response time can be calculated first. After calculating the average time, the average time can be used as the predicted response time of the request to be matched. In order to further improve the effectiveness of the determined predicted response time, a preset parameter can be pre-configured. After calculating the average time, the product of the average time and the preset parameter is used as the predicted response time. In this embodiment, the preset parameter can be 1.5. By using the product of the average time and the preset parameter as the predicted response time, the average time is avoided from ignoring the maximum request response time, thus improving the effectiveness of the determined predicted response time.

[0059] In this process, to further improve the effectiveness of the determined predicted response time and avoid it being too large or too small, the product of the time average and a preset parameter can be used as a candidate response time. It is then checked whether the candidate response time is within the valid time interval. If so, the candidate response time is determined as the predicted response data; otherwise, the interval boundary corresponding to the candidate response time within the valid time interval is used as the predicted response time. This achieves dynamic determination of the predicted response time, improving its effectiveness.

[0060] In one optional implementation of this embodiment, in the process of calculating the predicted response time of the request to be matched based on the request response time of historical execution requests, the average time of the request response time is first calculated, and the product of the average time and a preset parameter is calculated as the candidate response time. Then, it is detected whether the candidate response time is within the valid time interval. If so, the candidate response time is determined as the predicted response time. If not, the interval boundary corresponding to the candidate response time in the valid time interval is taken as the predicted response time.

[0061] Specifically, if the candidate response time is greater than the maximum value of the effective time interval, the maximum value of the effective time interval is determined as the predicted response time; if the candidate response time is less than the minimum value of the effective time interval, the minimum value of the effective time interval is determined as the predicted response time.

[0062] like Figure 4 As shown, the countdown processing provided in this embodiment can be implemented using the following steps: Step 401: Obtain the historical execution requests corresponding to the request type of the request to be matched.

[0063] Step 402: Calculate the average time of the request response time of historical execution requests, and calculate the product of the average time and the preset parameter as the candidate response time.

[0064] Step 403: Detect whether the candidate response time is within the valid time interval; If so, proceed to steps 404 and 406; If not, proceed to steps 405 to 406.

[0065] Step 404: Use the candidate response time as the preset response time.

[0066] Step 405: Use the interval boundary corresponding to the candidate response time in the effective time interval as the predicted response time.

[0067] Step 406: Perform countdown processing based on the predicted response time.

[0068] Step 407: If the request to be matched is matched with response data before the countdown ends, stop the countdown and record the successful response time.

[0069] Step 408: If no response data is found for the request to be matched after the countdown ends, the request response to the request to be matched is made based on the empty response data.

[0070] Furthermore, after responding to a request based on empty response data, the response failure time can be recorded. Recording the response success time and / or response failure time allows for updating the average time of the requests to be matched corresponding to that request type.

[0071] In addition, if no historical execution request corresponding to the request type to be matched is obtained, a countdown process based on the preset response time can be performed.

[0072] Step 202: Read the list of requests to be matched, and filter out the target requests that match the response data from the list of requests to be matched.

[0073] In practice, after obtaining the response data broadcast by the underlying service that does not contain a session identifier, the list of requests to be matched is read based on the response data, and the target request that matches the response data is filtered out from the list of requests to be matched. Optionally, the target request is converted to a coroutine suspended state before being written into the list of requests to be matched; after the response data matches the target request, the execution of the coroutine corresponding to the target request is resumed.

[0074] In this embodiment, the list of requests to be matched includes a list of requests to be executed that have been sent to the underlying service but have not received corresponding response data. Requests to be executed that have been sent to the underlying service but have not received corresponding response data can be requests to be matched or have a request status of "to be matched". Specifically, after a request to be executed is sent to the underlying service, it is updated to the list of requests to be matched as a request to be matched, or the request status of the request to be executed in the serialized request queue is updated to "to be matched". Correspondingly, during the process of reading the list of requests to be matched, the list of requests to be matched can be read directly. In addition, the list of requests to be matched can also be constructed by reading requests to be executed in the serialized request queue with a request status of "to be matched".

[0075] It should also be noted that, to improve the effectiveness of managing pending requests, a pending request in the pending request list is removed from the list once it is determined to be a target request that matches the response data; alternatively, a pending execution request in the serialized request queue with a pending-match status is removed from the serialized request queue once it is determined to be a target request that matches the response data. Furthermore, if no response data is matched after the countdown processing of a pending request or a pending execution request with a pending-match status has ended, the pending request will also be removed from the pending request list and / or the serialized request queue after responding to the request with empty response data.

[0076] In practical applications, requests and responses are matched to a certain extent. For example, if a request requests access to a target folder, the corresponding response will include the contents of that target folder. To ensure the integrity of the request and response data, the request will carry the folder identifier of the target folder, and the response will also carry the target folder identifier of that target folder. That is, there is a certain degree of similarity between the matched request and the response. Based on this, in this embodiment, in the process of filtering out target requests that match the response data from the list of requests to be matched, the similarity between the response data and the requests to be matched in the list of requests to be matched can be calculated to filter out target requests that match the response data. In specific execution, the higher the similarity between the response data and the requests to be matched, the higher the match between the response data and the requests to be matched.

[0077] In one optional implementation of this embodiment, during the process of filtering out target requests that match the response data from the list of requests to be matched, the response features in the response data and the request features of the candidate requests to be matched in the list of requests to be matched are first extracted. Then, the feature similarity is calculated based on the request features and the response features. If the feature similarity is greater than the similarity threshold, the candidate request to be matched is determined as the target request. If the feature similarity is less than or equal to the similarity threshold, the next candidate request to be matched in the list of requests to be matched is obtained, and the operation of extracting the request features of the candidate requests to be matched in the list of requests to be matched is returned.

[0078] It should be noted that in this embodiment, the target request matching the response data is filtered out by calculating the feature similarity between the response features and the request features. That is, the filtering efficiency of the target request is improved by similarity calculation, and the accuracy of the identified target request is also improved.

[0079] To reduce the waste of computing resources, in one optional implementation of this embodiment, during the process of calculating feature similarity based on request features and response features, the key response features in the response features are compared with the key request features in the request features. If they are consistent, feature similarity is calculated based on the baseline response features in the response features and the baseline request features in the request features. If not, the next candidate request to be matched is obtained from the list of requests to be matched, and the operation of extracting the request features of the candidate requests to be matched from the list of requests to be matched is returned.

[0080] Optionally, response features may include all or part of the parameters in the response data; the response features of the response data and the request features of the target request that matches the response data may have the same feature name and / or feature identifier; the response features of response data that matches different types of requests may have different feature names and / or feature identifiers. For example, response features may include the folder name, response time, data type, and / or number of data items in the response data.

[0081] For example, during data interaction between the application layer and the DVR service, the request to be executed (the request to be matched) is a data query request with multiple album types and / or multiple perspectives. Based on this, the request to be matched may include the requested album ID (Identifier), the requested perspective ID, the requested time, and the video data type. Correspondingly, the response data may include the response album ID, the response perspective ID, the response time, and the number of videos. The response features can be the response album ID, the response perspective ID, the response time, and the video data type in the response data. The corresponding request features can be the requested album ID, the requested perspective ID, the requested time, and the video data type. The key response features can be the response time and the video data type. The corresponding key request features can be the request time and the video data type.

[0082] For example, during data interaction between the application layer and the 360-degree surround view service, the request to be matched is a real-time video request with multiple perspectives. The request to be matched may include the requested viewpoint type, the requested resolution, and the requested frame rate. The requested viewpoint type may include forward-looking, backward-looking, and / or panoramic types. Correspondingly, the response data may include the response viewpoint type, the response resolution, the response frame data address, and / or the stream status. The response features can be the response viewpoint type and the response resolution in the response data, and the corresponding request features can be the requested viewpoint type and the requested resolution.

[0083] For example, during the data interaction between the application layer and the navigation service, the request to be matched is a real-time traffic query request. The request to be matched may include the request route ID, the set of request road segment IDs, the request time, and the route data type. Correspondingly, the response data may include the response route ID, the set of response road segment IDs, the response time, and the route data type. Based on this, the response features can include the response route ID, the set of response road segment IDs, the response time, and the route data type, and the request features can include the request route ID, the set of request road segment IDs, the request time, and the route data type.

[0084] The data types in this embodiment include pre-configured data types corresponding to different requests to be executed; for example, if the data corresponding to the request to be executed is video, then the data type is video data type; as another example, if the data corresponding to the request to be executed is route, then the data type is route data type.

[0085] Furthermore, the key response feature can be one or more of the above response features, and the key request feature can also be one or more of the above request features; for example, the key response feature includes the folder name and / or data type; the key request feature also includes the folder name and / or data type; the response feature other than the key response feature is the baseline response feature; the request feature other than the key request feature is the baseline request feature.

[0086] like Figure 5 As shown, the process of filtering target requests provided in this embodiment can be implemented using the following steps: Step 501: Extract response features from the response data.

[0087] Step 502: Extract the request features of the candidate requests to be matched from the list of requests to be matched.

[0088] Step 503: Compare whether the key response features in the response features are consistent with the key request features in the request features; If so, proceed to steps 504 to 505; If not, return to step 502.

[0089] In the specific execution process, if the key response feature includes response time and the key request feature includes request time, then in the process of comparing whether the response time and request time are consistent, it can be detected whether the time difference between the response time and request time is less than a time difference threshold. If so, it is determined that the response time and request time are consistent; otherwise, it is determined that the response time and request time are inconsistent. The time difference threshold can be a pre-set threshold, such as 3 seconds. Alternatively, the time difference threshold can also be the aforementioned time average or the predicted response time; this embodiment does not limit this to any particular threshold.

[0090] Step 504: Calculate the feature similarity based on the baseline response feature in the response features and the baseline request feature in the request features.

[0091] Step 505: Detect whether the feature similarity is greater than the similarity threshold; If so, proceed to step 506; If not, return to step 502.

[0092] Step 506: Determine the candidate requests to be matched as the target requests that match the response data.

[0093] It should be noted that the requests to be matched in the list of requests to be matched can carry priorities. When retrieving candidate requests to be matched from the list of requests to be matched, requests with higher priorities can be retrieved first.

[0094] Step 203: Response to the target request based on the response data.

[0095] In practice, after filtering out the target request whose response data matches the list of requests to be matched, the request and response to the target request are made according to the response data, so that the user can perceive the correspondence between the request and the response.

[0096] In the specific execution process, after obtaining the response data, in order to avoid the impact on system load caused by multiple requests for the same response data, in this embodiment, the response data can be cached after obtaining it. If a target request to be executed is obtained, the target feature similarity is calculated based on the target request features of the target request to be executed and the response features of the response data. If the target feature similarity is greater than the similarity threshold, the request response of the target request to be executed is made based on the response data. In this way, the same request to be executed is deduplicated, the number of requests is reduced, and the system load is reduced.

[0097] It should be noted that the process of calculating the target feature similarity based on the target request features and response features of the response data is similar to the process of calculating the feature similarity described above. Please refer to the relevant content above. This embodiment will not repeat the details here.

[0098] In addition to converting the requests to be matched into a coroutine suspension state as described above, in this embodiment, each request to be executed can also be executed through an independent thread to avoid mutual interference.

[0099] In summary, the response processing method provided in this embodiment deploys an intermediate processor located between the application layer and the underlying service to receive response data broadcast by the underlying service that does not contain a session identifier, filter out target requests that match the response data from the list of requests to be matched, and respond to the target requests based on the response data. In this way, it not only achieves the matching of response data that does not contain a session identifier with the target requests, but also improves the accuracy of the matching results.

[0100] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0101] like Figure 6 As shown, Figure 6 This is an illustrative flow diagram of a response processing method provided in an embodiment of this application. Figure 2 The method includes the following steps: Step 601: Obtain the requests to be executed from the serialized request queue.

[0102] Step 602: Send a pending request to the underlying service to execute the request, and update the request status of the pending request to a pending match status.

[0103] Step 603: Obtain the response data broadcast by the underlying service that does not contain a session identifier.

[0104] Step 604: Read at least one pending request in the serialized request queue that is in a pending matching state.

[0105] Step 605: Based on the response characteristics of the response data and the request characteristics of the requests to be matched, filter out the target requests that match the response data from at least one request to be matched.

[0106] Step 606: Response to the target request based on the response data.

[0107] It should be noted that any one or more of steps 601 to 606 can be combined with any one or more of steps 201 to 203 to form a new implementation method according to the needs of implementation and deployment. In addition, any one or more technical features can be selected in steps 601 to 606 and combined with any one or more technical features provided in steps 201 to 203 to form a new implementation method according to the actual deployment needs. Alternatively, any one or more technical features in steps 601 to 606 can be replaced with any one or more technical features provided in steps 201 to 203 to form a new implementation method according to the actual deployment needs. These will not be elaborated on here.

[0108] like Figure 7 As shown, Figure 7 A schematic structural diagram of a response processing apparatus provided for embodiments of this application, the apparatus comprising: The acquisition module 701 is used to acquire response data broadcast by the underlying service; the response data does not contain a session identifier; The filtering module 702 is used to read the list of requests to be matched and filter out the target requests that match the response data from the list of requests to be matched. The response module 703 is used to respond to the target request based on the response data.

[0109] Optionally, the filtering module 702 is specifically used for: extracting response features from the response data and extracting request features from the candidate requests to be matched in the list of requests to be matched; calculating feature similarity based on the request features and the response features; determining the candidate requests to be matched as the target requests if the feature similarity is greater than a similarity threshold; and obtaining the next candidate requests to be matched in the list of requests to be matched if the feature similarity is less than or equal to the similarity threshold, and returning to perform the operation of extracting request features from the candidate requests to be matched in the list of requests to be matched.

[0110] Optionally, when calculating feature similarity based on the request features and the response features, the filtering module 702 is specifically used to: compare whether the key response features in the response features are consistent with the key request features in the request features; if so, calculate feature similarity based on the baseline response features in the response features and the baseline request features in the request features; if not, obtain the next candidate request to be matched in the list of requests to be matched, and return to perform the operation of extracting the request features of the candidate requests to be matched in the list of requests to be matched.

[0111] Optionally, the apparatus further includes a request execution module, which is specifically used to: obtain requests to be executed in a serialized request queue; send the requests to be executed to the underlying service for request execution; and determine the requests to be executed as requests to be matched and update the list of requests to be matched.

[0112] Optionally, the device further includes a countdown module, which is specifically used to: obtain historical execution requests corresponding to the request type of the request to be matched; calculate the predicted response time of the request to be matched based on the request response time of the historical execution requests, and perform countdown processing based on the predicted response time; if the request to be matched does not match response data after the countdown processing is completed, perform a request response for the request to be matched based on empty response data.

[0113] Optionally, when the countdown module calculates the predicted response time of the request to be matched based on the request response time of the historical execution requests, it specifically performs the following: calculates the time average of the request response times, and calculates the product of the time average and a preset parameter as a candidate response time; detects whether the candidate response time is within a valid time interval; if so, determines the candidate response time as the predicted response time; if not, takes the interval boundary corresponding to the candidate response time in the valid time interval as the predicted response time.

[0114] Optionally, the target request is converted to a coroutine suspended state before being written into the list of requests to be matched; the execution of the coroutine corresponding to the target request is resumed after the response data matches the target request.

[0115] Optionally, the device further includes a caching module, which is specifically used for: caching the response data; if a target request to be executed is obtained, calculating a target feature similarity based on the target request features of the target request to be executed and the response features of the response data; and if the target feature similarity is greater than a similarity threshold, performing a request response for the target request to be executed based on the response data.

[0116] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0117] Figure 8 This is a structural schematic diagram of a vehicle provided in an embodiment of this application.

[0118] For example, such as Figure 8As shown, the vehicle includes a memory 801 and a processor 802. The memory 801 stores executable program code 8011, and the processor 802 is used to call and execute the executable program code 8011 to perform a response processing method.

[0119] This embodiment can divide the vehicle into functional modules based on the above method example. For example, each function can be assigned to a separate module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. When dividing each functional module according to its corresponding function, the vehicle may include: an acquisition module, a filtering module, and a response module, etc. It should be noted that all relevant content of each step involved in the above method embodiment can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0120] The vehicle provided in this embodiment is used to execute the above-described response processing method, and thus can achieve the same effect as the above-described implementation method.

[0121] When using integrated units, the vehicle may include a processing module and a storage module. The processing module is used to control and manage the vehicle's movements. The storage module is used to support the vehicle in executing relevant program code and data.

[0122] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits as disclosed in this application. The processor may also be a combination of computing functions, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0123] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described response processing method embodiments.

[0124] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described response processing method embodiments at runtime.

[0125] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0126] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described response processing method embodiments.

[0127] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described response processing method embodiments.

[0128] The beneficial effects of the above embodiments can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0129] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0130] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0131] In the description of this application, it should be understood that if the terms "upper", "lower", "front", "rear", "left" and "right" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the position or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0132] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0133] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A response processing method characterized by, The method, applied to an intermediate processing layer between the application layer and underlying services, includes: Obtain the response data broadcast by the underlying service; the response data does not contain a session identifier; Read the list of requests to be matched, and filter out the target requests that match the response data from the list of requests to be matched; The request response to the target request is made based on the response data.

2. The method of claim 1, wherein, The step of filtering the target request that matches the response data from the list of requests to be matched includes: Extract response features from the response data, and extract request features from the candidate requests to be matched in the list of requests to be matched; Calculate feature similarity based on the request features and the response features; If the feature similarity is greater than the similarity threshold, the candidate request to be matched is determined as the target request; If the feature similarity is less than or equal to the similarity threshold, obtain the next candidate request to be matched in the list of requests to be matched, and return to perform the operation of extracting the request features of the candidate requests to be matched in the list of requests to be matched.

3. The method of claim 2, wherein, The step of calculating feature similarity based on the request features and the response features includes: Compare whether the key response features in the response features are consistent with the key request features in the request features; If so, calculate the feature similarity based on the baseline response feature in the response features and the baseline request feature in the request features; If not, obtain the next candidate request to be matched in the list of requests to be matched, and return to perform the operation of extracting the request features of the candidate requests to be matched in the list of requests to be matched.

4. The method of claim 1, wherein, Before the operation of obtaining the response data broadcast by the underlying service is executed, the method further includes: Retrieve requests to be executed from the serialized request queue; Send the pending request to the underlying service for request execution, and determine the pending request as a matching request and update it to the matching request list.

5. The method according to claim 4, characterized in that, After the steps of sending the request to be executed to the underlying service for request execution, and determining the request to be executed as a matching request and updating it to the matching request list for execution, the method further includes: Obtain the historical execution requests corresponding to the request type of the request to be matched; Based on the request response time of the historical execution requests, calculate the predicted response time of the request to be matched, and perform countdown processing based on the predicted response time; If no response data is found for the request to be matched after the countdown process ends, the request response to the request to be matched is made based on empty response data.

6. The method according to claim 5, characterized in that, The step of calculating the predicted response time of the request to be matched based on the request response time of the historical execution requests includes: Calculate the average time of the request response time, and calculate the product of the average time and a preset parameter as a candidate response time; Detect whether the candidate response time is within the valid time interval; If so, the candidate response time is determined as the predicted response time; If not, the interval boundary corresponding to the candidate response time in the effective time interval shall be taken as the predicted response time.

7. The method according to claim 1, characterized in that, The target request is converted to a goroutine suspended state before being written into the list of requests to be matched; the execution of the goroutine corresponding to the target request is resumed after the response data matches the target request.

8. The method according to claim 1, characterized in that, The method further includes: Cache the response data; If a target request to be executed is obtained, the target feature similarity is calculated based on the target request features of the target request to be executed and the response features of the response data; If the similarity of the target features is greater than the similarity threshold, a request response is made to the target request to be executed based on the response data.

9. A response processing device, characterized in that, An intermediate processing layer running between the application layer and the underlying services, the device comprising: The acquisition module is used to acquire response data broadcast by the underlying service; the response data does not contain a session identifier. The filtering module is used to read the list of requests to be matched and filter out the target requests that match the response data from the list of requests to be matched. The response module is used to respond to the target request based on the response data.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for implementing the steps of the response processing method as described in any one of claims 1 to 8 when executing the computer program.

Images