Reverse HTTP Gateway Streaming Across DMZ

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current network architectures require proprietary protocols and introduce complexity, message size limitations, and delays when accommodating incoming requests from external networks to internal networks through a demilitarized zone (DMZ), as they often involve different communication protocols before and after the DMZ and require temporary buffering of messages.

Innovation Solution

Implementing a reverse HTTP gateway architecture within the DMZ that uses the same communication protocol, such as HTTP 1.1, on both sides to establish a persistent connection between the internal server and the reverse HTTP gateway, allowing direct streaming of messages without the need for proprietary protocols, thereby reducing complexity and delays.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If proprietary protocols are implemented between the reverse HTTP gateway and internal server, then communication can be established across the DMZ, but device complexity and protocol compatibility issues increase

Engineering Contradiction:
Improvecommunication reliabilityVSAvoidprotocol complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The reverse HTTP gateway is designed to use standard HTTP protocols for multiple functions: establishing connections, transmitting requests, and receiving responses. This universal use of HTTP eliminates the need for proprietary protocols while maintaining reliable communication across the DMZ boundary.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The reverse HTTP gateway acts as an intermediary that uses standard HTTP protocols to mediate communication between external clients and internal servers. By using HTTP as the universal language, it simplifies the communication layer while maintaining security and reliability through the DMZ architecture.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If messages are buffered temporarily in the DMZ for protocol conversion, then communication between different protocols is enabled, but message size limitations and buffering delays occur

Engineering Contradiction:
Improveprotocol adaptabilityVSAvoidbuffering delay
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent extracts the protocol conversion function entirely by using standard HTTP protocols on both sides of the DMZ. This eliminates the need for temporary buffering and message extraction for conversion, allowing messages to flow directly through the gateway without delays or size limitations imposed by conversion processes.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

By using HTTP protocols throughout the entire communication path including across the DMZ, the system enables continuous message streaming without interruption for protocol conversion. This maintains the continuity of useful action by allowing messages to be transmitted and processed without buffering delays.

Inventive Principle:
Principle #20Continuity of useful action

3Reliability

If a reverse invoke server polls for work in the DMZ, then security is maintained by preventing direct connections, but productivity decreases due to polling overhead

Engineering Contradiction:
ImprovesecurityVSAvoidrequest processing speed
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

Instead of the reverse invoke server polling for work, the system inverts the approach by allowing the internal server to initiate connections to the reverse HTTP gateway using standard HTTP protocols. This inversion eliminates polling overhead while maintaining security, as the firewall still controls which connections are permitted.

Inventive Principle:
Principle #13The other way round (Inversion)

Solution Approach 2:

The internal server performs self-service by initiating connections to the reverse HTTP gateway when needed, eliminating the need for continuous polling by the gateway. This self-service mechanism improves productivity by allowing requests to be processed immediately when needed while maintaining security through firewall-controlled connection initiation.

Inventive Principle:
Principle #25Self-service

Data Source

PatentEP2031817B1Systems and/or methods for streaming reverse HTTP gateway and network including the same
Publication Date: 2012.11.07 SOFTWARE AG USA INC
  • EP2031817B1 patent drawingFigure 1~2
  • EP2031817B1 patent drawingFigure 3
  • EP2031817B1 patent drawingFigure 4~5

AI summary

In certain example embodiments of this invention, there is provided systems and/or methods for a steaming reverse HTTP gateway, and/or networks including the same. In such a network, a reverse HTTP gateway is located within a demilitarized zone (DMZ) disposed between public (or external) and private (or internal) networks for providing security therebetween. Requests from external clients may be streamed from the external network to the internal network over various connections and ports, including a substantially persistent reverse connection between an internal server and a reverse HTTP gateway. The reverse HTTP gateway architecture of certain example embodiments removes the need for proprietary protocols implemented between the reverse HTTP gateway located in the DMZ and the internal server located in the internal network. In certain example embodiments, the reverse HTTP gateway architecture is configured to leverage the capabilities of HTTP 1.1.