HIDL Request Routing for Multi-Client Server Processing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional HIDL interface implementations restrict a server end to fixedly receive requests from a single client end, preventing simultaneous processing of requests from multiple client ends.
Innovation Solution
A method where requests from multiple invokers carry identifying information, allowing a server end to process and return responses to the correct invoker through an interface proxy module, enabling multiple client ends to utilize a single server end.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a server end of an HIDL interface is fixedly registered with a client end of one HIDL interface, then the interface implementation is simple and stable, but the server end cannot simultaneously process requests from multiple client ends
Solution Approach 1:
The server end of the HIDL interface is designed to serve multiple client ends simultaneously. The server end maintains a mapping relationship between multiple client ends and their respective invokers, allowing a single server end to handle requests from multiple clients through unified processing and routing mechanisms.
Solution Approach 2:
A proxy module is introduced as an intermediary between the HIDL interface and the server end. This proxy module manages the binding relationships between client ends and invokers, and routes requests appropriately. The proxy module abstracts the complexity of multi-client management from the server end, enabling the server end to focus on processing while the proxy handles the coordination.
2Device complexity
If multiple client ends invoke different HIDL interfaces with separate server ends, then each interface can be independently implemented, but the system requires more server ends and increases system complexity
Solution Approach 1:
Multiple server ends that would traditionally handle different HIDL interfaces are merged into a single unified server end. This unified server end processes requests from multiple client ends through a common processing pipeline, reducing the total number of server end instances while maintaining the ability to handle diverse interface requests through standardized processing mechanisms.
3Productivity
If a server end processes requests from multiple invokers, then resource utilization improves, but identifying and returning responses to the correct invoker becomes complex
Solution Approach 1:
The system implements a feedback mechanism where the proxy module receives processing results from the server end and uses invoker identification information to route responses back to the correct invoker. The proxy module maintains a mapping between active invokers and their corresponding client ends, enabling accurate response routing based on feedback from the processing stage.
Solution Approach 2:
The proxy module performs preliminary actions by establishing and maintaining mapping relationships between invokers and client ends before request processing begins. This pre-established mapping structure enables efficient response routing without requiring complex real-time decision-making during the response return phase.
Data Source
AI summary
A request processing method includes: Requests of a plurality of invokers are sent to a Server end of a first device interface. The request carries information indicating an invoker to which the request belongs. Then, response data that corresponds to each request and that is returned by the server end of the first device interface is received. The response data corresponding to the request carries information indicating an invoker to which the request belongs. Further, for the response data corresponding to each request, an invoker to which the response data corresponding to the request belongs can be identified based on the information that is carried in the response data corresponding to the request and that is used to indicate the invoker to which the request belongs, and the response data corresponding to the request can be returned to the invoker to which the response data corresponding to the request belongs.