Lightweight Polling via Network Layer Interception
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing polling techniques in communications systems, such as COMET-based solutions and traditional polling, face challenges in managing server resources efficiently, leading to high bandwidth and CPU usage, especially when content is not frequently updated, resulting in high latency and scalability issues.
Innovation Solution
A lightweight polling technique where the network layer intercepts initial polling requests when content is unavailable, responding with a 'connection refused' message, and only opens the port when updated information is available, allowing subsequent polling requests to be handled by a topic server, thereby reducing server load and improving latency.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional polling or COMET-based solutions are used for notification mechanisms, then clients can receive updates about topics, but server bandwidth and CPU resources are consumed excessively, especially when content is not frequently updated
Solution Approach 1:
The server performs preliminary action by opening the port and announcing availability before content is actually updated. Clients poll for availability rather than continuously requesting content, reducing unnecessary server processing when no updates are pending.
Solution Approach 2:
Instead of continuous polling or long-held requests, the system uses periodic availability checks where clients periodically query whether content is available. This transforms continuous resource consumption into discrete periodic interactions, reducing overall server load.
2Loss of time
If continuous polling is implemented to ensure low latency notifications, then clients receive timely updates, but server load increases significantly
Solution Approach 1:
The server opens the port in advance and announces content availability before actual content updates occur. This allows clients to detect availability immediately through periodic polling, achieving low latency without requiring continuous server processing or maintaining long-held requests.
Solution Approach 2:
The availability announcement acts as an intermediary mechanism between the server's content update state and the client's polling requests. Instead of clients directly triggering heavy server processing on every poll, the announcement system mediates by pre-signalizing availability, reducing the computational burden on the server during polling operations.
3Reliability
If the server maintains long-held HTTP requests for COMET-based solutions, then data can be pushed to clients without explicit requests, but server resources are consumed and scalability is reduced
Solution Approach 1:
Instead of the server maintaining long-held requests and pushing data to clients (COMET approach), the system inverts the interaction by having clients periodically poll for data availability. The server responds to these polling requests when content is available, eliminating the need for the server to maintain persistent connections and manage complex push infrastructure.
Solution Approach 2:
Clients perform self-service by autonomously polling for content availability according to their own timing requirements. This eliminates the need for the server to actively manage and maintain long-held requests for each client, significantly reducing server resource consumption and improving scalability while preserving the ability to push data when updates occur.
Data Source
AI summary
At a network layer of a physical server, during a time when updated information about a topic is unavailable, a first polling request for information about the topic is obtained from a client. The first polling request is directed to a particular port. The first polling request is responded to with a connection refused message, from the network layer of the physical server. In response to updated information about the topic becoming available, a topic server is launched on the physical server and the particular port is opened. A second polling request for information about the topic, directed to the particular port, is obtained from the client. The second polling request is responded to, from the topic server on the physical server, with a message to the client including the updated information about the topic.