Asynchronous Notification Transport Method Selection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In HTTP frameworks, clients can only send requests, while servers can only respond, making it challenging for servers to send asynchronous notifications to clients without being solicited, particularly due to firewall restrictions and limitations in existing HTTP protocols.
Innovation Solution
Implementing a negotiation mechanism between clients and servers to select and probe the viability of transport methods such as Reverse HTTP, Websocket, and Long Polling for delivering asynchronous notifications, allowing the server to choose the most suitable method based on availability and firewall traversal.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the server uses traditional HTTP response mechanism to send notifications, then the client can receive notifications, but the server cannot initiate unsolicited notifications to the client due to HTTP protocol limitations and firewall restrictions
Solution Approach 1:
The system dynamically selects transport methods based on client capabilities and network conditions. The client initially requests notifications via HTTP, but the system can switch to WebSocket or Reverse HTTP callbacks depending on what the client supports and what works through firewalls, making the notification mechanism adaptive rather than static
Solution Approach 2:
The system introduces intermediary mechanisms to bridge the client-server communication gap. Reverse HTTP uses a callback URI as an intermediary where the client exposes an endpoint that the server can call. WebSocket acts as an intermediary protocol that upgrades the HTTP connection to enable full-duplex communication, allowing the server to push notifications without traditional HTTP limitations
2Adaptability or versatility
If the system supports multiple transport methods for notifications, then the adaptability improves, but the device complexity increases due to negotiation and probing mechanisms
Solution Approach 1:
The client performs preliminary actions by including capability information in its initial notification request. The client indicates which transport methods it supports (HTTP, WebSocket, Reverse HTTP callback) before the server needs to select a method, reducing the complexity of the negotiation process by having the client do the work upfront
Solution Approach 2:
The system uses feedback mechanisms where the server probes the selected transport method by sending a test notification, and the client responds to confirm whether the method works. Based on this feedback, the system can retry with alternative transport methods if the first choice fails, making the complexity management systematic rather than ad-hoc
3Reliability
If the server probes transport method viability before sending notifications, then the notification delivery success rate improves, but the time required for establishment increases
Solution Approach 1:
The system performs a minimal probe by sending just one test notification to verify transport method viability, rather than extensive testing. This partial action is sufficient to determine whether the transport method works, balancing reliability verification with time efficiency
Solution Approach 2:
If the first probe fails, the system discards that transport method and recovers by trying alternative transport methods from the client's capability list. The client's pre-declared supported methods serve as a recovery plan, allowing the system to quickly move to backup options without extensive re-negotiation
Data Source
AI summary
Methods and apparatus, including computer program products, are provided for transport method selection of asynchronous notifications. In some example embodiments, there may be provided a method that includes sending, by a client, a hypertext transfer protocol request for at least one asynchronous notification to be sent by a server to the client, the hypertext transfer protocol request including at least one proposed transport method for carrying the at least one asynchronous notification; determining, by the client, whether a first transport method selected by the server from the at least one proposed transport method is successfully established; and when the determination is that the first transport method is not established successfully, sending, by the client, another hypertext transfer protocol request to the server, the other hypertext transfer protocol request including at least one other proposed transport method. Related systems, methods, and articles of manufacture are also described.