Server Retry Overload Protection via Client Status Tracking

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing protocols like TCP for streaming media transmission lead to data under run issues due to automatic data transfer rate adjustments, while using UDP to maintain a constant rate can result in network overload from excessive retry requests, particularly from clients or malicious actors.

Innovation Solution

Implementing a server-side system to dynamically track client status based on retry request parameters such as frequency, validity, and software version, allowing the server to determine whether to process new retry requests and transmit queued packets, thereby preventing network overload.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the server retransmits packets for every client retry request to ensure reliable delivery, then client data reception reliability is improved, but network overload occurs due to excessive retry requests from problematic clients or attackers

Engineering Contradiction:

Improvedata reception reliabilityVSAvoidnetwork throughput

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

The server dynamically adjusts its response to retry requests based on real-time client status evaluation. Healthy clients receive normal retry service while unhealthy clients have their retry requests rejected, allowing the system to adapt to varying client behaviors and prevent network overload

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

Different quality of service is provided to different clients based on their individual status. Healthy clients receive full service while unhealthy clients receive limited or no service, allowing the server to maintain reliability for legitimate users while blocking abusive traffic

Inventive Principle:

Principle #3Local quality

2Reliability

If the server processes all retry requests to maintain data transfer completeness, then media presentation quality is improved, but network resources are consumed by excessive retry traffic from unhealthy clients

Engineering Contradiction:

Improvemedia presentation qualityVSAvoidnetwork resource consumption

Core Design Contradiction:

ReliabilityVSLoss of energy

Solution Approach 1:

The system segments clients into different categories (healthy and unhealthy) based on their retry request patterns. This segmentation allows the server to apply different processing rules to different client groups, ensuring quality service for legitimate users while conserving resources from abusive clients

Inventive Principle:

Principle #1Segmentation

3Reliability

If the server accepts retry requests from all clients to ensure complete data delivery, then data transfer completeness is improved, but the network becomes vulnerable to attacks from hostile actors simulating clients

Engineering Contradiction:

Improvedata transfer completenessVSAvoidnetwork security

Core Design Contradiction:

ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The server performs preliminary evaluation of client status before processing retry requests. By identifying and blocking unhealthy clients in advance, the system prevents potential attacks from compromising network security while still maintaining data transfer completeness for legitimate clients

Inventive Principle:

Principle #9Preliminary anti-action

Data Source

PatentUS7765305B2Retry request overload protection

Publication Date: 2010.07.27 ZHIGU HLDG

AI summary

Retry request overload protection is described. A server system determines a client status based on retry requests received from the client. The client status may be used to determine whether to accept and/or process new retry requests received from the client and/or whether to transmit previously requested retry packets to the client. The client status may be based on a number of retry requests received from the client, a number of retry packets requested by the client, and/or a number of bytes of data associated with the retry requests received from the client. The client status may be updated periodically, enabling a non-favorable client status to be modified to a favorable client status if retry requests recently received from the client are within favorable limits.