Elastic Routing Loop Detection in Hierarchical Caching Networks

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing caching hierarchies face the challenge of infinite loop formation during failover operations due to the potential for peers to point to one another in their next-peer lists, which can lead to inefficient content retrieval and network congestion.

Innovation Solution

Implementing elastic routing with a specialized peer-to-peer message header that tracks traversed peers and modifies peer behavior to prevent loops by discarding selections that have already received the message, ensuring a non-circular traversal to access a lower tier peer or returning a response when all peers in the list have been exhausted.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If peers are configured with next-tier lists to enable failover, then reliability is improved, but infinite loops may form causing network congestion and inefficient content retrieval

Engineering Contradiction:
Improvefailover capabilityVSAvoidinfinite loops
Core Design Contradiction:
ReliabilityVSObject-generated harmful factors

Solution Approach 1:

The patent implements loop detection by tracking the path of requests through peers and checking for circular references. When a peer receives a request, it records the path taken and checks whether the current peer appears in the recorded path. This feedback mechanism allows the system to detect loops and prevent them from causing infinite circulation of requests.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The patent performs preliminary path tracking before processing the full request. By maintaining a record of the request path and checking for the current peer in this path beforehand, the system can prevent loop formation before it causes network congestion or inefficient content retrieval.

Inventive Principle:
Principle #10Preliminary action

2Productivity

If multiple peers are configured in same-tier lists for failover, then productivity is improved, but device complexity increases due to additional list management

Engineering Contradiction:
Improvecontent retrieval efficiencyVSAvoidlist management complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent implements self-service by having each peer automatically manage its own failover process. Peers independently monitor their ability to access lower-tier peers and autonomously switch to alternative peers in the same tier without requiring centralized control or complex manual configuration management.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent introduces dynamic list management where the next-tier and same-tier lists are not static but can be adjusted based on real-time conditions. Peers can dynamically modify their failover paths based on current network state, allowing flexible adaptation to changing conditions while managing complexity through automated decision-making.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS10044602B2Network failover and loop detection in hierarchical networks
Publication Date: 2018.08.07 DRNC HOLDINGS INC
  • US10044602B2 patent drawing
  • US10044602B2 patent drawing
  • US10044602B2 patent drawing

AI summary

Some embodiments provide loop detection and loop prevention mechanisms for messaging passing in between peers in a multi-tier hierarchy. In some embodiments, the messaging header is modified to track which peers have received a copy of the message. Each peer appends its identifier to the message header before passing the message to another peer. When selecting a receiving peer, the sending peer ensures that the receiving peer is not already identified in the message header. If the receiving peer has already received the message, then another peer from a next-peer list is selected to receive the message. If all peers in the next-peer have been traversed, the sending peer returns an error message via a reverse traversal of the peers in the message header.