Intermediary Units for Reliable UDP Data Transfer
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current data transfer protocols, such as TCP and UDP, face inefficiencies in transferring large files over the Internet, with TCP being overly reliable but inefficient and UDP being unreliable, especially for long-distance transmissions, and existing solutions require extensive updates to user devices and networks.
Innovation Solution
The use of intermediary electronic processing units (acceleration servers) that manage data packets with additional fields for reception confirmation, logical order, and error correction within the UDP protocol, allowing for efficient and reliable data transfer between these units using both TCP and UDP packets, without requiring specific physical connections or updates to the network.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If TCP protocol is used for data transfer, then reliability is improved, but transmission efficiency deteriorates due to large header overhead and retransmission mechanisms
Solution Approach 1:
The patent introduces intermediary electronic processing units (acceleration servers) that act as mediators between TCP senders and UDP receivers. These intermediaries receive reliable TCP data streams, convert them into UDP packets with embedded reliability information, and forward them efficiently. This intermediary layer allows TCP's reliability mechanisms to coexist with UDP's efficiency, resolving the contradiction between reliability and transmission efficiency.
2Productivity
If UDP protocol is used for data transfer, then transmission efficiency is improved, but reliability deteriorates due to lack of error correction and order guarantee
Solution Approach 1:
The patent segments the reliability assurance function from the data transfer function. Instead of relying on UDP's inherent unreliability, the system segments reliability information (checksums, sequence numbers, acknowledgment requests) into separate data fields within UDP packets. This allows UDP to maintain its efficiency while embedded reliability mechanisms handle error correction and order guarantee.
Solution Approach 2:
The patent implements feedback mechanisms within the UDP packet structure, including acknowledgment request fields and sequence number tracking. The intermediary units send feedback packets to confirm successful reception and request retransmission of lost or corrupted data. This feedback loop provides UDP-based transfer with reliability comparable to TCP while maintaining UDP's transmission efficiency.
3Productivity
If existing UDP-based solutions are implemented, then efficiency is improved, but device complexity increases due to required software updates on all user devices
Solution Approach 1:
The patent places the complex protocol conversion and reliability management functions in intermediary electronic processing units rather than in end-user devices. This means acceleration servers handle TCP-to-UDP conversion, reliability tracking, and error correction, while standard TCP senders and UDP receivers require no software modifications. The intermediary absorbs the device complexity, allowing efficient UDP-based transfer without widespread software updates.
Data Source
Figure 1~2
Figure 3~4
Figure 5
AI summary
The method is for the transfer of data of a message subdivided in fragments from a first intermediary electronic processing unit (43) to a second intermediary electronic processing unit (45); before the transfer, the first unit (43) receives the data encapsulated in the payload of data packets of the TCP type from a sender electronic processing unit (41) and decapsulates them; after the transfer, the second unit (45) encapsulates data in the payload of data packets of the TCP type and transmits them to a recipient electronic processing unit (47); the transfer takes place by means of data packets of the UDP type; the first unit (43) also inserts in the payload (32) of UDP packets; a first data field (C1) containing an identifier of a connection between the sender unit (41) and the recipient unit (47), a second data field (C2) containing an identifier of the message to be transferred, and a third data field (C3) containing a number that identifies the position of a fragment within the message to be transferred.