Content Distribution Network Using Common IP Address for Edge Caching
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing content distribution networks face inefficiencies in directing user requests to the most appropriate content cache due to the need for network address translation and the complexity of dynamic user location and network topology changes, which is not within the expertise of content providers.
Innovation Solution
A content distribution system utilizing a common internet protocol address for all content servers within subdomains, with access servers routing traffic to the topologically closest content server, allowing for efficient access and redundancy without address translation, and using load balancers to distribute requests among multiple content servers.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Device complexity
If a single central server is used for content distribution, then system complexity is reduced, but distribution efficiency and user access speed deteriorate
Solution Approach 1:
The patent divides the centralized content distribution system into multiple geographically distributed content caches (edge servers) located at different network access points. Each cache stores copies of content and serves local users independently, segmenting the monolithic central server into distributed units that reduce complexity while improving distribution efficiency through localized access.
2Productivity
If multiple separate content caches are deployed, then distribution efficiency improves, but the complexity of directing user requests to the appropriate cache increases
Solution Approach 1:
The patent introduces DNS servers as intermediaries that automatically handle the complexity of routing user requests to appropriate content caches. When a user requests content, the DNS server translates the content provider's URL into the specific IP address of the nearest or most appropriate content cache, shielding users and content providers from the complexity of cache location management while maintaining efficient distribution.
3Loss of time
If DNS translation is implemented to direct users to appropriate caches, then request routing efficiency improves, but the requirement for content providers to identify user network location increases complexity
Solution Approach 1:
The patent enables DNS servers to autonomously perform the function of identifying and translating user network locations without requiring content providers to implement complex location identification systems. The DNS infrastructure self-services the routing function by automatically resolving URLs to the appropriate cache IP addresses based on user location, eliminating the need for content providers to engage in network topology analysis or dynamic location tracking.
Data Source
Figure 1
Figure 1a
Figure 2
AI summary
A partitioned network has several subdomains (1, 2, 3,) each having a respective access server (10, 20, 30) and each serving a plurality of end users (11, 12; 21, 22; 31, 32). Each access server (10, 20, 30) is connected to a respective content cache (13, 23) or a set of such caches (130, 131, 132), which stores content and downloads it to end users on request. An alternative routing (19, 29) may be available between an access server (10) and a content cache (23) other than its associated cache (13), for use in exceptional circumstances. All the content caches (13, 23), are given the same IP address, "W.X.Y.Z". Each access server (10, 20, 30) operates exclusively in a geographic sub-domain, and recognises the IP address W.X.Y.Z as relating uniquely to its respective associated content cache 13, (23, 23) This means that the configuration of each access server (10, 20, 30) to handle content caching/distribution/streaming can be the same regardless of its location in the network. Any end user (10) can therefore obtain content from the cache (13) which is topologically closest, using the common IP address W.X.Y.Z. No address translation or mapping is required to route requests to the correct local content server. If the access server (10) is unable to connect to the associated content server (13), it is configured to forward traffic to another content cache (23), by tunnelling the request to an access server (20) associated with that second cache. The second access server (20) recognises the address W.X.Y.Z as being that of its own associated content server (23), rather than the content server (13) associated with the first access server (10), and forwards the request accordingly. The content can then be returned to the address of the requesting user.