HTTP Seeking Module for Random Access File Retrieval

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current HTTP protocols lack an abort operation, making it inefficient to request data from servers for video formats like AVI that require random access, leading to slow data retrieval and throughput issues when seeking within files.

Innovation Solution

Implementing a HTTP seeking module that varies data block sizes, starting with small requests and exponentially increasing them, allowing for efficient data retrieval over the same HTTP connection without closing and reopening connections, while using a parameter module to manage request sizes and optimize throughput.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If the entire file is cached to enable random access, then random access capability is improved, but memory usage and initial loading time increase significantly

Engineering Contradiction:
Improverandom access capabilityVSAvoidmemory usage
Core Design Contradiction:
Ease of operationVSQuantity of substance

Solution Approach 1:

The patent divides the file into multiple data blocks that are requested separately through HTTP connections. Instead of caching the entire file, the system segments the file access into smaller units (blocks) that can be fetched on-demand, enabling random access without loading the complete file into memory.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system performs preliminary actions by establishing HTTP connections and requesting specific data blocks before they are needed for playback. The client proactively seeks and caches small portions of data in advance, preparing random access capability without committing entire file resources upfront.

Inventive Principle:
Principle #10Preliminary action

2Adaptability or versatility

If a new HTTP connection is opened for each seek operation to enable random access, then random access flexibility is improved, but connection establishment overhead and processing time increase

Engineering Contradiction:
Improveseek flexibilityVSAvoidconnection establishment time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent makes a single HTTP connection serve multiple functions by enabling it to request different data blocks at different positions in the file. The same connection is reused for sequential and random access operations, eliminating the need to establish new connections for each seek operation while maintaining access flexibility.

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

Solution Approach 2:

The system maintains continuous HTTP connections that remain active during file access operations. By keeping connections open and reusable, the system eliminates repeated connection establishment and teardown cycles, maintaining continuous data flow while supporting random seek operations through block requests.

Inventive Principle:
Principle #20Continuity of useful action

3Quantity of substance

If small data blocks are requested frequently to enable random access without caching entire files, then memory usage is reduced, but request overhead and throughput decrease

Engineering Contradiction:
Improvememory usageVSAvoiddata retrieval throughput
Core Design Contradiction:
Quantity of substanceVSProductivity

Solution Approach 1:

The patent dynamically adjusts the size of data blocks requested based on the access pattern and connection state. The system varies block sizes adaptively, requesting smaller blocks when seeking randomly and larger blocks when sequential access is possible, optimizing throughput while maintaining random access capability and managing memory usage effectively.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS8856378B2Fast HTTP seeking
Publication Date: 2014.10.07 RED HAT INC
  • US8856378B2 patent drawing
  • US8856378B2 patent drawing
  • US8856378B2 patent drawing

AI summary

An apparatus and a method for requesting data from a server over an HTTP connection. In one implementation, a method includes in response to reading at least a portion of a random access file from a server via an HTTP connection, requesting a first amount of data at a first location in the random access file, receiving the first amount of data from the server, determining a second amount of data to be requested, the determining based on a growth rate parameter, and prior to completing the reading of the first amount of data received from the server, requesting the second amount of data at a second location in the random access file that is different than the first location, wherein the size of the second amount of data being requested is greater than the size of the first amount of data.