Throttling Software Process Communication via Ready-State Checks

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In network systems, slave processors often become overwhelmed with data communications from the master processor, leading to data loss and increased network congestion due to the need for acknowledgment messages and potential synchronization issues, resulting in inefficient data transfer.

Innovation Solution

A throttling algorithm is implemented in the master processor to determine if slave processors are busy, delaying or throttling data transmission to busy destinations until they are available, thereby reducing network traffic and data loss by sending data only when destinations are not overwhelmed.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If the master processor sends data to slave processors at high speed, then data transfer efficiency is improved, but the slave processor becomes overwhelmed and drops data

Engineering Contradiction:
Improvedata transfer efficiencyVSAvoiddata delivery reliability
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The master processor performs preliminary actions by checking whether the slave processor is ready to receive data before actually transmitting. The system determines the ready state of the slave processor in advance and only transmits when the slave is ready, preventing data overflow and drop while maintaining efficient transfer.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If the slave processor sends acknowledgment messages back to the master processor, then data reception status is confirmed, but network traffic increases and congestion worsens

Engineering Contradiction:
Improvedata reception confirmationVSAvoidnetwork congestion
Core Design Contradiction:
ReliabilityVSObject-generated harmful factors

Solution Approach 1:

The invention extracts and eliminates the unnecessary acknowledgment message mechanism from the communication protocol. Instead of having the slave processor send back acknowledgment messages, the system uses a unidirectional transmission approach where the master processor simply stops transmitting when the slave is not ready, thereby confirming receipt without additional traffic.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The system implements a simplified feedback mechanism where the master processor monitors the slave processor's ready state and adjusts transmission accordingly. This feedback loop operates at the transmitter side rather than requiring explicit acknowledgment messages from the receiver, reducing network traffic while maintaining reliability.

Inventive Principle:
Principle #23Feedback

3Reliability

If the slave processor asks the master processor to stop sending data, then data loss is prevented, but system traffic increases

Engineering Contradiction:
Improvedata loss preventionVSAvoidsystem traffic
Core Design Contradiction:
ReliabilityVSObject-generated harmful factors

Solution Approach 1:

The master processor performs preliminary checking of the slave processor's ready state before transmission. By determining in advance whether the slave is ready to receive data, the system prevents data loss without requiring the slave to send stop requests, thereby avoiding additional system traffic.

Inventive Principle:
Principle #10Preliminary action

4Productivity

If continuous data transmission occurs between master and slave processors, then productivity is maintained, but synchronization issues and inconsistent states occur

Engineering Contradiction:
Improvecontinuous data transferVSAvoidsystem synchronization
Core Design Contradiction:
ProductivityVSStability of the object's composition

Solution Approach 1:

The master processor performs preliminary determination of the slave processor's ready state before each transmission. This preliminary check ensures that data is only sent when the slave is ready, maintaining synchronization and preventing inconsistent states while allowing continuous productive operation when conditions permit.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS7610412B2Throttling communication between software processes
Publication Date: 2009.10.27 HEWLETT PACKARD ENTERPRISE DEV LP
  • US7610412B2 patent drawing
  • US7610412B2 patent drawing
  • US7610412B2 patent drawing

AI summary

A throttling process for throttling communications between software processes, where data streams are sent between a source and one or more destinations. The method first determines if any of the destinations are busy. If one or more of the destinations are busy, the process performs a throttling action before sending the data stream to the busy destinations.