Client Listener Port for Direct Server Communication

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current client-server architectures require unnecessary complexity and intermediaries in communications, leading to latency and increased network load, as the publicly-accessible server must mediate all interactions between client and internal server computers, and clients must handle multiple connections and logic for individual server communications.

Innovation Solution

A client process retrieves a listener port identifier and sends it along with a remotely-executable command to a server process, allowing direct communication between the client and remote server processes without intermediaries, using either connection-oriented or connectionless transport layer protocols, enabling the client to receive responses directly even without initial remote server information.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a publicly-accessible server computer mediates all communications between client and internal server computers, then centralized control and security are improved, but device complexity and communication latency increase

Engineering Contradiction:
Improvecentralized controlVSAvoidserver complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system segments the communication architecture by introducing listener processes on client computers that handle direct connections from remote servers. This divides the mediation function between the publicly-accessible server (which receives initial commands) and client-side listeners (which handle direct responsive communications), reducing the complexity burden on the central server while maintaining controlled access.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The listener process acts as an intermediary on the client computer, receiving responsive communications directly from remote servers without requiring all traffic to pass through the publicly-accessible server. This intermediary enables direct peer-to-peer communication while maintaining the security framework of the original architecture.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If a publicly-accessible server computer mediates all communications, then security control is improved, but communication latency increases

Engineering Contradiction:
Improvesecurity controlVSAvoidcommunication latency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

Communication paths are segmented into two phases: initial command transmission through the secured publicly-accessible server, and responsive communication through direct client-server connections. This segmentation eliminates unnecessary routing delays for responsive messages while preserving security controls during the initial connection establishment phase.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Security verification is performed in advance when the client process sends the listener port identifier to the server. Once verified, direct communication channels are established, allowing subsequent responsive communications to proceed without repeated security checks, thus reducing latency while maintaining security.

Inventive Principle:
Principle #10Preliminary action

3Adaptability or versatility

If client computer sends requests to multiple internal server computers individually, then direct access to multiple servers is improved, but client logic complexity increases

Engineering Contradiction:
Improvemulti-server accessVSAvoidclient logic
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The listener process provides a universal interface on the client computer that can receive responsive communications from any remote server. Instead of implementing separate connection logic for each server, the client uses a single listener mechanism that handles all incoming responsive communications, regardless of which remote server sent them.

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

Solution Approach 2:

The client computer's listener process autonomously manages incoming connections from multiple remote servers without requiring complex client-side routing logic. The listener receives messages, identifies the appropriate process to handle them, and delivers them accordingly, making the client self-sufficient in managing multi-server communications.

Inventive Principle:
Principle #25Self-service

4Adaptability or versatility

If client computer handles multiple connections to different servers, then direct server access is improved, but network load increases

Engineering Contradiction:
Improvedirect server accessVSAvoidnetwork load
Core Design Contradiction:
Adaptability or versatilityVSLoss of energy

Solution Approach 1:

The system extracts the connection management burden from the client computer by having remote servers directly connect to client listeners. This eliminates the need for the client to maintain multiple outgoing connections to different servers, reducing the network load and connection management overhead on the client side while preserving direct access capabilities.

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentUS10140121B2Sending a command with client information to allow any remote server to communicate directly with client
Publication Date: 2018.11.27 ORACLE INT CORP
  • US10140121B2 patent drawing
  • US10140121B2 patent drawing
  • US10140121B2 patent drawing

AI summary

A process that executes client software in a computer, hereinafter client process, starts execution of at least a portion of server software, hereinafter listener. The client process retrieves from the listener, an identifier of a port in the computer, at which the listener waits to receive one or more messages, which may contain commands. The client process connects to a server process in another computer and sends only to the server process, at least a command and client information that includes at least the port identifier of its listener. Any remote computer(s) that may receive and execute the command, use the client information to send back information related to the command, directly to the port identifier of the listener started by the client process. Any messages received at the listener's port identifier are processed, e.g. by displaying any output generated in execution of the command by the remote computer(s).