HTTP Client Pre-sent Requests for Asynchronous Message Delivery

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current HTTP protocols are inadequate for asynchronous, low-latency message delivery from an HTTP server to an HTTP client, especially when the client has limited resources or is behind a firewall, as they are designed for request-response patterns and lack assured delivery mechanisms, leading to delays and network traffic inefficiencies.

Innovation Solution

The method involves an HTTP client sending HTTP GET requests to an HTTP server, which stores these requests and responds with messages or after a timeout, using HTTP/1.1 pipelining for concurrent delivery and message identifiers for assured delivery, allowing the client to acknowledge receipt and maintain a message delivery window.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the client uses periodic polling to receive messages from the server, then the client can receive messages, but message delivery latency increases and network traffic becomes excessive

Engineering Contradiction:

Improvemessage deliveryVSAvoidmessage delivery latency

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The client sends HTTP GET requests in advance to the server before messages are available, establishing a ready state for immediate message delivery. The server stores these pre-sent requests and responds immediately when messages arrive, eliminating the need for periodic polling and reducing delivery latency.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The server monitors message availability and sends responses to stored HTTP GET requests as soon as messages are ready. This feedback mechanism allows the client to receive messages immediately without waiting for the next poll cycle, significantly reducing latency while maintaining reliable delivery.

Inventive Principle:

Principle #23Feedback

2Loss of time

If the server sends messages asynchronously to the client, then low latency delivery is achieved, but assured delivery cannot be guaranteed

Engineering Contradiction:

Improvemessage delivery latencyVSAvoidassured delivery

Core Design Contradiction:

Loss of timeVSReliability

Solution Approach 1:

The client acknowledges receipt of messages by sending HTTP GET requests with message identifiers back to the server. This feedback loop allows the server to confirm delivery and maintain assurance, while the asynchronous nature of the protocol keeps latency low.

Inventive Principle:

Principle #23Feedback

Solution Approach 2:

The client pre-sends HTTP GET requests to the server, establishing a ready state that enables immediate asynchronous response. This preliminary action allows the server to deliver messages with minimal latency while the subsequent acknowledgment mechanism ensures reliable delivery confirmation.

Inventive Principle:

Principle #10Preliminary action

3Productivity

If the client runs an HTTP server to receive messages, then asynchronous messaging is enabled, but the client's RAM and CPU footprint increases

Engineering Contradiction:

Improveasynchronous messaging capabilityVSAvoidclient resource footprint

Core Design Contradiction:

ProductivityVSDevice complexity

Solution Approach 1:

Instead of having the client run an HTTP server to receive messages, the invention inverts the approach by having the client send HTTP GET requests to the server. The server stores these requests and responds asynchronously when messages are ready, enabling asynchronous messaging without requiring the client to run a server.

Inventive Principle:

Principle #13The other way round (Inversion)

Solution Approach 2:

The client uses standard HTTP GET requests for multiple purposes: establishing communication, requesting messages, and acknowledging receipt. This multi-functional approach eliminates the need for separate server software on the client, reducing resource footprint while maintaining asynchronous messaging capability.

Inventive Principle:

Principle #6Universality (Multi-functionality)

4Reliability

If the client sends frequent HTTP GET requests to poll for messages, then message delivery is reliable, but network traffic increases excessively

Engineering Contradiction:

Improvemessage delivery confirmationVSAvoidnetwork traffic volume

Core Design Contradiction:

ReliabilityVSLoss of energy

Solution Approach 1:

The client sends HTTP GET requests in advance and stores them at the server. When messages are ready, the server responds immediately to these pre-sent requests, eliminating the need for continuous polling and significantly reducing network traffic while maintaining reliable delivery.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The server uses stored HTTP GET requests as feedback mechanisms that are responded to immediately when messages are available. This eliminates the need for frequent polling requests, reducing network traffic volume while ensuring reliable message delivery through the acknowledgment mechanism.

Inventive Principle:

Principle #23Feedback

Data Source

PatentUS7747694B2Low latency and assured delivery using HTTP

Publication Date: 2010.06.29 SOLACE CORP

AI summary

In a method of performing the asynchronous delivery of messages from a server to a client, the server receives the messages for the client from a message source. The server and client communicate over a packet network using an asymmetric protocol that requires request messages to be originated from the client to the server. At least one request message is sent in advance from the client to the server, and these request messages are stored at the server. When the server receives a message for the client from the message source, it forwards the message to the client as a response to a stored request message.