DNS Query Segmentation for Client Instance Routing

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing communication systems lack efficient methods to route different types of client instances to specific endpoints based on their platform, version, and build numbers, leading to potential miscommunication or resource inefficiencies, especially when dealing with badly behaving clients or beta versions.

Innovation Solution

The proposed solution involves forming DNS queries that include the platform ID, version, and build number in reverse order, allowing the domain name system to map these queries to distinct IP addresses, enabling the routing of client instances to different endpoints, including non-existent addresses to isolate problematic clients.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a traditional DNS query without client identification is used, then the address system is simple and easy to operate, but different client instances cannot be routed to appropriate endpoints based on their platform, version, or build number

Engineering Contradiction:

Improveclient routing capabilityVSAvoidaddress query structure

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The DNS query is segmented into multiple components: platform ID, version number, and build number are separately extracted and formatted into distinct DNS name segments. This allows the system to handle different client types through a modular query structure without overwhelming complexity.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The patent adds new dimensions to the DNS query by incorporating platform ID, version, and build number as additional hierarchical levels in the DNS name structure. This transforms a simple domain name lookup into a multi-dimensional client identification system that can distinguish between different client instances.

Inventive Principle:

Principle #17Another dimension (Dimensionality change)

2Measurement precision

If the DNS query includes platform ID, version, and build number to identify client type, then client routing precision is improved, but the DNS query becomes more complex and harder to process

Engineering Contradiction:

Improveclient type identification accuracyVSAvoidDNS query processing

Core Design Contradiction:

Measurement precisionVSDevice complexity

Solution Approach 1:

The patent transforms the client identification parameters (platform ID, version, build number) into DNS-compatible format by reversing their order and converting them into DNS name segments. This parameter transformation maintains the identification precision while adapting to DNS processing constraints.

Inventive Principle:

Principle #35Parameter changes

Solution Approach 2:

The patent inverts the conventional DNS query structure by placing client identification information (platform ID, version, build number) as suffixes rather than prefixes. This inversion allows the DNS system to process queries efficiently while maintaining detailed client differentiation capabilities.

Inventive Principle:

Principle #13The other way round (Inversion)

3Reliability

If a comprehensive client identification system is implemented, then miscommunication between client types can be prevented, but the system requires complex directory services and infrastructure

Engineering Contradiction:

Improvecommunication reliabilityVSAvoiddirectory service infrastructure

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The patent makes the DNS system multi-functional by using it not only for standard domain name resolution but also for client type identification and routing. This universal use of DNS eliminates the need for separate complex directory services while maintaining reliable client communication.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The DNS query acts as an intermediary mechanism that carries client identification information between the client and the address system. This intermediary approach enables reliable routing without requiring additional complex infrastructure, as the DNS system itself mediates the client identification process.

Inventive Principle:

Principle #24Intermediary (Mediator)

4Productivity

If existing communication systems are used without specialized routing methods, then the system is simple to operate, but resource inefficiencies occur when dealing with badly behaving clients or beta versions

Engineering Contradiction:

Improveresource management efficiencyVSAvoidsystem operation simplicity

Core Design Contradiction:

ProductivityVSEase of operation

Solution Approach 1:

The patent applies local quality by providing different DNS query handling for different client types. The system maintains simple operation for standard clients while automatically applying specialized routing for badly behaving clients or beta versions, optimizing resource management without complicating general operation.

Inventive Principle:

Principle #3Local quality

Data Source

PatentUS11057242B2Address system

Publication Date: 2021.07.06 MICROSOFT TECHNOLOGY LICENSING LLC

AI summary

Device, address system and computer program product for routing data from the device to an endpoint over a network. The device executes an instance of a client for routing the data. An address query for requesting a network address of the endpoint is formed in dependence on the type of the client instance, and the address query is sent to the address system. The address system determines an endpoint address based on the address query such that the endpoint address is dependent upon the type of the client instance and sends the endpoint address to the device. Data is then routed from the device to the endpoint address over the network.