Worker Process Pipe Communication for Multi-Protocol Server Handling
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional web servers experience inefficiencies and reduced robustness due to delays from 'process hops' and shared communication ports, which can lead to diminished performance when handling thousands of requests per minute, especially when worker processes fail to complete requests.
Innovation Solution
A system with a process manager that connects listeners to worker processes via pipes, allowing multiple protocols to be supported, enabling flexible handling of requests by launching appropriate protocol handlers for each request, and configuring listeners to route requests to a single queue or disable applications as needed.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If conventional web servers use process hops and shared communication ports to handle requests, then the server can manage multiple protocols and worker processes, but the server experiences delays and reduced robustness when handling thousands of requests per minute
Solution Approach 1:
The patent extracts the communication port sharing mechanism from the conventional architecture. Each worker process is assigned a dedicated communication port instead of sharing ports, eliminating the bottleneck caused by port contention and process hops while maintaining multi-protocol support capability
Solution Approach 2:
The patent segments the communication architecture by creating direct, dedicated communication channels between each worker process and the listener. This segmentation eliminates the shared resource bottleneck and allows parallel request processing without interference, improving throughput while maintaining protocol versatility
2Ease of operation
If conventional web servers use process hops to route requests to worker processes, then the server can dynamically assign requests, but the server experiences delays that diminish efficiency when handling high volumes of requests
Solution Approach 1:
The patent implements preliminary action by pre-establishing direct communication ports for each worker process before requests arrive. This eliminates the need for dynamic process hopping and routing decisions during request handling, as requests can be directly routed to the appropriate pre-configured worker process, reducing delay while maintaining routing flexibility
Solution Approach 2:
The patent introduces a direct communication port as an intermediary between the listener and worker processes, replacing the conventional process hop mechanism. This intermediary enables direct, efficient communication while preserving the ability to flexibly route requests to appropriate worker processes based on protocol and application requirements
3Device complexity
If worker processes share communication ports with the web server, then the server can simplify the architecture, but the server experiences reduced robustness when worker processes fail to complete requests
Solution Approach 1:
The patent segments the communication architecture by assigning dedicated communication ports to each worker process instead of sharing ports. This segmentation isolates communication failures to individual worker processes, preventing cascading failures and improving overall system reliability while maintaining manageable architectural complexity through clear, dedicated communication paths
Solution Approach 2:
The patent extracts the shared communication port mechanism from the architecture and replaces it with dedicated ports for each worker process. This extraction eliminates the reliability issue caused by port sharing while worker process failures, as each process has its own isolated communication channel that doesn't affect other processes or the server
Data Source
AI summary
A server system has a process manager, listeners and worker processes in which the listeners connect to worker processes. At server start-up, each listener connects with the process manager via a pipe published by the process manager. The process manager then provides information to each listener associating applications to application pools, and applications for which the listener is to “listen”. When the listener receives a request for which it is to listen, the listener starts a queue for the application or associated application pool. The process manager launches an appropriate worker process to handle requests in the listener's protocol. The worker process then makes a connection with the listener.