WO2001089172A2 - Meta content delivery network system - Google Patents
Meta content delivery network system Download PDFInfo
- Publication number
- WO2001089172A2 WO2001089172A2 PCT/US2001/015859 US0115859W WO0189172A2 WO 2001089172 A2 WO2001089172 A2 WO 2001089172A2 US 0115859 W US0115859 W US 0115859W WO 0189172 A2 WO0189172 A2 WO 0189172A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- cdn
- server
- meta
- dns
- cdns
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
- H04L12/1403—Architecture for metering, charging or billing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
- H04L12/1442—Charging, metering or billing arrangements for data wireline or wireless communications at network operator level
- H04L12/1446—Charging, metering or billing arrangements for data wireline or wireless communications at network operator level inter-operator billing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/30—Managing network names, e.g. use of aliases or nicknames
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/35—Network arrangements, protocols or services for addressing or naming involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address or functional addressing, i.e. assigning an address to a function
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/101—Server selection for load balancing based on network conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1021—Server selection for load balancing based on client or server locations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/10015—Access to distributed or replicated servers, e.g. using brokers
Definitions
- the invention relates to network traffic management in a computer environment. More particularly, the invention relates to traffic scheduling between multiple independent content delivery networks in a computer environment.
- a Content Delivery Network is collection of caching, streaming, storage, and other servers distributed throughout the Internet in order to deliver content closer to the end user, avoiding the "middle mile” problem.
- CDN's provide two main benefits to their users (in this case the user is the customer or content owner, not the end user).
- the first is reduction of traffic at the origin site. Every request that arrives at the CDN is a request not arriving at the origin site. This means that the origin site will have less work to do as it utilizes the CDN more and more.
- the type of work that is being removed is often very different than what will continue to be directed at the origin site. As an example, all of the requests for images which result in many connections to a server are removed from the origin while connections that need access to the database remain. This allows the origin site to be tuned for the database type requests that it will be receiving.
- a CDN of at least one POP will provided this benefit to a customer.
- the second benefit is increased performance for the delivery of the content by reducing the network delay between the browser and the content. This is done by placing servers in locations near the end users and using a system to direct end users to the "best" server. Each customer will have a different group of end users. Some will need full global coverage while other may only need certain parts of the world.
- a network provider building their own CDN has a very cost effective solution for solving the first problem of reducing origin site load. Owning their own network, they often see their internal costs for using it as very low, and as a result can price a CDN solution very low. The ability of a given network provider to solve the second issue with only their own connectivity, will not work for all customers.
- CDNs Today there are two types of CDNs generally available: facilities-based CDNs (also referred to as an on-net CDN) and multi-network CDNs.
- a facilities-based CDN has deployment limited to a single service provider's network and points of presence (POPs).
- POPs points of presence
- a multi-network, CDN has servers distributed on many different service provider networks and POPs.
- multi-network CDNs provide higher performance, availability, redundancy, and scalability than facilities-based CDNs, due to the fact that no one service provider network controls all the content providers (servers) and/or the eyeballs (clients). Also, not many service providers have sufficient coverage and POPs to distribute and deliver content. Thus, a multi-network CDN will outperform a facilities-based CDN in all cases.
- the invention provides a meta content delivery network system.
- the system provides load balancing and traffic scheduling across multiple content delivery networks (CDN) in a computer network.
- CDN content delivery networks
- the invention allows CDN providers to designate the availability of their networks and to assign clients to specific CDNs.
- a preferred embodiment of the invention provides a Meta CDN scheduling layer above multiple content delivery networks (CDN). This combined Meta CDN provides customers with the combined scale and reach of all the underlying CDNs.
- Meta CDN scheduling is performed by a Meta CDN DNS (MCD) server.
- MCD Meta CDN DNS
- the MCD server is authoritative for all domains given to customers of the Meta CDN service.
- the MCD contains information about which CDNs participate in which CDN domain names.
- Each CDN provides to the Meta CDN a domain name that will refer to their CDN's portion of the entire Meta CDN for that Meta CDN customer.
- the MCD receives domain name query requests from local DNSs. It selects the proper CDN address based on a predefined capacity reservation of CDNs and statically mapped preferences for certain clients and directs the local DNS requests to the proper CDN address.
- the local DNS finds which DNS server is authoritative for the CDN address and sends a request to that authoritative DNS server.
- the authoritative DNS server performs load balancing for the servers within its CDN and returns an A record to the local DNS which forwards the A record to the requesting client.
- the requesting client uses the A record to make a request to a server within the proper CDN.
- the MCD defines weights for each CDN which are used to control a weighted scheduling algorithm for the CDNs.
- the weights are dynamically adjusted to change CDN priorities.
- the MCD allocates Name Server (NS) records dynamically to the local DNS.
- NS Name Server
- Each CDN keeps the MCD updated with all of the scheduling devices that each CDN uses.
- FIG. 1 is a block schematic diagram of an on-net architecture according to the invention
- Fig. 2 is a block schematic diagram of an overlay architecture according to the invention.
- Fig. 3 is a block schematic diagram of a content proxying example according to the invention.
- Fig. 4 is a block schematic diagram of a Meta CDN scheduling layer above multiple CDNs according to the invention.
- Fig. 5 is a block schematic diagram of an authoritative Meta CDN DNS (MCD) server for a group of CDNs according to the invention.
- Fig. 6 is a block schematic diagram of an exemplary MCD load balancing and redirection packet flow according to the invention.
- the invention is embodied in a meta content delivery network system in a computer environment.
- a system according to the invention provides load balancing and traffic scheduling across multiple content delivery networks (CDN) in a computer network.
- CDN content delivery networks
- the invention allows CDN providers to designate the availability of their networks and to assign clients to specific CDNs.
- the invention provides a Meta Content Delivery Network (CDN) DNS server that enables multiple independent CDN providers to maximize the bandwidth of their network as well as their revenue.
- CDN Meta Content Delivery Network
- CDNs are a collection of servers deployed at different points on the Internet.
- a scheduling layer is provided above them that determines which server a given client should use. This scheduling is based on the load/availability of each server and their relative proximity, or latency, to the clients (users). By directing clients to the least loaded and lowest latency server, download time is greatly reduced as well as the load on the origin servers.
- CDNs There are two main architectures in use by CDNs: on-net and overlay. Both methods have the CDN as authoritative for the domain name to be accelerated through DNS. Varying degrees of importance are placed on the role DNS takes in making the actual server selection.
- an on-net deployment is a collection of servers 102, 103, 104, 105 arranged around the edge of a single network 101. This allows content to be served from the "on network" side of peering points, reducing the traffic across the backbone of the on network. In addition, it places servers 102, 103, 104, 105 close to clients 106, 107, 108, 109, 110 who are on network.
- routing techniques can be used to direct clients to the server with the least latency to a given client. This can b e achieved by broadcasting routes for the IPs of the servers out all interfaces that connect this network to other networks. This causes off net client requests to find the closest entry point to the on network where they immediately find a server with that IP. Because the CDN owns the network, it is able to deploy servers in locations such as peering points to make the service compelling. Network traffic still needs to cross the peering point for clients that originate from off net.
- overlay networks deploy their servers across multiple networks 202, 203, 204, 205. Because these deployments span networks 202, 203, 204, 205, scheduling using routing tricks is difficult or impossible. Instead, overlay architectures are usually designed around a smart DNS server 201 that makes the determination of where to send users at DNS resolution time.
- the smart DNS server 201 uses the source IP address of the client making the request to determine latency from the client to servers in the network.
- the Smart DNS server 201 also uses server load and availability information to direct the client to the best possible server.
- the content In both architectures, to have content served from a CDN, the content must be under a domain that the CDN is authoritative for. This is done by the content owner delegating a domain name to the CDN or by the CDN creating a name in their domain for the customer to use. The latter tends to work better as it avoids any possible misconfiguration of the DNS on the part of the content owner.
- the CDN has to understand what type of content the customer needs to support and may have content types mapped into domain names.
- the customer wants to use the CDN for SSL content, they may use the hostname ssl-customer.cdn.com.
- For HTTP content they may use the hostname http-customer.cdn.com. This allows the CDN to have specialized servers for different types of content.
- CDNs since they are not the creators of the content, cache content on behalf of the creator. Not all CDNs support all content types, or if they do, they may go about supporting a protocol using different solutions. How Content Gets In
- origin servers 301 , 302, 303 keep master copies of content and CDN servers 303, 304, 305, 306 cache content. Requests sent to CDN servers include enough information to allow them to fetch the content from the origin servers if the content is not already cached.
- HTTP and SSL protocol requests normally use one of two methods: embedded URL information and Host directive mapping.
- CDN servers would notice the HTTP host header customer.cdn.com and would have a table that maps it to www.customer.com.
- Host based directive approaches have a few draw backs.
- Third, clients that do not send the host directive in their request will not be able to be supported with this solution.
- CDN URL could look like this: http://customer.cdn.com/www.customer.com/path/to/object.gif
- the CDN server can find the name of the origin site in the request (in this case in-between the first two slashes). This approach reduces the complexity of having to ensure that the CDN servers have access in some way to the host directive mapping and solves the problem of supporting clients that do not send a host directive in their requests. This approach requires changing the URLs that refer to the content to a URL formatted as above.
- CDN servers are thought of like origin sites. An external mechanism is used to ensure the CDN servers are in sync with the origin site. This could be thought of as a mirroring solution. It tends to work well for large file size content or protocols that do not lend themselves well to proxying.
- the Meta CDN 401 provides a scheduling layer above multiple content delivery networks 402, 403, 404, 405, 406.
- This combined Meta CDN 407 provides customers with the combined scale and reach of all the underlying CDNs. The benefits to the customer is greater than that which can b e provided by any of the underlying CDNs.
- Meta CDN scheduling is performed by a Meta CDN DNS (MCD) server 501.
- the MCD server 501 is authoritative for all domains given to customers of the Meta CDN service 502.
- the MCD is provided with information about which CDNs participate in which CDN domain names.
- Each CDN provides to the Meta CDN a domain name that will refer to their CDN's portion of the entire Meta CDN for that Meta CDN customer.
- Table I shows an example of the information used by the MCD to correlate Meta CDN domain names to the proper CDN.
- Redirection, or load-balancing operates as follows:
- the browser 606 sends a request 601 to its local DNS 607 for customerl .meta.com
- the local DNS 607 goes through DNS and finds the Meta DNS server (MCD) 608 to be authoritative for this domain and sends a query 602 to the MCD 608.
- MCD Meta DNS server
- the MCD 608 looks at the request and returns an answer based on predefined capacity reservation and statically mapped preferences for certain clients 602. An example of this is if one of the CDNs is known to be better suited to server requests from a particular ISP, it will be mapped to do so.
- the answer comes from the Meta DNS in the form of a CNAME.
- the Meta DNS controls the TTL on the CNAME and thus controls how long a user is scheduled to a particular CDN. In this example, from Table I, the answer is customerl .cdn-1.com.
- the local DNS 607 finds who is authoritative for customer1.cdn-1.com and sends a request 603 to the DNS server of CDN-1 609.
- the DNS for CDN- 1 609 performs the load balancing for the servers within CDN-1 and returns an A record 603 to the local DNS 607.
- the local DNS 607 returns this A record 604 to the client 606.
- the client 606 makes a request 605 to the server within CDN-1 611.
- the Domain Name that the customer uses is controlled by the Meta CDN. Issues such as failed page loads can result if sites use any of the underlying CDN domain names to reference CDN content.
- the Meta CDN supports any Protocol of the underlying CDNs. Any of the CDNs that do not support a particular protocol will not be scheduled to for those domain names.
- Meta CDN Content never enters the Meta CDN but instead enters each of the underlying CDNs directly through the method used for a particular protocol. This is very simple for "pull" based protocols like HTTP and HTTPS, but requires a Meta CDN entry point for "push” content.
- This invention solves many of the problems that are encountered in an independent CDN situation.
- the Meta CDN schedules to the CDN's scheduling devices, giving the CDN the final decision of which server within to utilize. By returning a CNAME, it is up to the client to find the device authoritative for the name.
- the Meta CDN can alternatively give out NS records dynamically, requiring that each CDN keep the Meta CDN in sync with all of the scheduling devices that they use.
- the Meta CDN controls how long a user will be handed off to a CDN before the Meta CDN has the chance to change this decision.
- the name that the client is looking up is the name Meta CDN name. Any TTLs given out by each CDN on their records will not affect the Meta CDN's ability to redirect users.
- the Meta CDN decides which CDNs a customer will be able to utilize.
- the Meta CDN maps Meta Hostnames to any amount of the CDNs. This can be done for different billing issues, as well as for feature support.
- the Meta CDN can pre map customers to a specific CDN.
- the Meta CDN allows static mapping tables to be updated on a client IP basis. This allows the Meta CDN operator to determine which CDN they want the traffic for the source IP sent.
- the amount of traffic to be scheduled to each CDN by the Meta CDN can be based on percentages.
- a simple user interface is available to the operator from the CDNs to indicate their availability to accept more traffic.
- the Meta CDN provides the ability to defines weight for each CDN. These weights act to control a weighted round robin scheduling algorithm in the Meta CDN.
- a simple interface is provided to allow each CDN to indicate to the Meta CDN their availability. Weights are also dynamically allocated to allow for adjustments.
- the Meta CDN has the ability to reserve capacity of CDNs to ensure traffic flow.
- Meta CDN redirects traffic to and from CDNs, it has the ability to get billing information directly from the redirected traffic. This enables the Meta CDN provider to accurately bill for the amount of traffic that is redirected for any customer.
- Each CDN generates billing information for each Meta CDN customer and provides it to the Meta CDN.
- the Meta CDN aggregates the billing information for each customer.
- the Meta CDN provides a simple user interface for the operator to retrieve and report billing information and administrate billing parameters.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
Claims
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/276,088 US7185052B2 (en) | 2001-05-16 | 2001-05-16 | Meta content delivery network system |
AU2001264629A AU2001264629A1 (en) | 2000-05-16 | 2001-05-16 | Meta content delivery network system |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US20491400P | 2000-05-16 | 2000-05-16 | |
US60/204,914 | 2000-05-16 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2001089172A2 true WO2001089172A2 (en) | 2001-11-22 |
WO2001089172A3 WO2001089172A3 (en) | 2002-04-11 |
Family
ID=22760001
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2001/015859 WO2001089172A2 (en) | 2000-05-16 | 2001-05-16 | Meta content delivery network system |
Country Status (2)
Country | Link |
---|---|
AU (1) | AU2001264629A1 (en) |
WO (1) | WO2001089172A2 (en) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2007111588A1 (en) * | 2006-03-28 | 2007-10-04 | Thomson Licensing | Centralized scheduler for content delivery network |
DE10311247B4 (en) * | 2003-03-14 | 2008-01-31 | Inos Automationssoftware Gmbh | Portable device for detecting a position and dimensions of an object |
GB2456026A (en) * | 2007-12-26 | 2009-07-01 | Contendo Inc | CDN balancing and sharing platform |
US20110299544A1 (en) * | 2010-06-04 | 2011-12-08 | David Lundgren | Method and system for managing bandwidth by a broadband gateway |
WO2016041846A1 (en) * | 2014-09-17 | 2016-03-24 | British Telecommunications Public Limited Company | Content delivery network |
US9756124B1 (en) * | 2012-07-12 | 2017-09-05 | Juniper Networks, Inc. | Content delivery network referral |
EP3451614A4 (en) * | 2017-01-22 | 2019-05-01 | Huawei Technologies Co., Ltd. | Dispatching method and device in content delivery network |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0817444A2 (en) * | 1996-07-01 | 1998-01-07 | Sun Microsystems, Inc. | System for context-dependent name resolution |
WO1998050863A1 (en) * | 1997-05-02 | 1998-11-12 | Whowhere? Inc. | An improved method for providing an internet protocol address with a domain name server |
EP0889418A2 (en) * | 1997-06-30 | 1999-01-07 | Sun Microsystems, Inc. | Abstract URL resolution via relocation service |
EP0959601A1 (en) * | 1998-05-21 | 1999-11-24 | Sun Microsystems, Inc. | A system and method for server selection for mirrored sites |
WO2000004458A1 (en) * | 1998-07-14 | 2000-01-27 | Massachusetts Institute Of Technology | Global document hosting system utilizing embedded content distributed ghost servers |
-
2001
- 2001-05-16 WO PCT/US2001/015859 patent/WO2001089172A2/en active Application Filing
- 2001-05-16 AU AU2001264629A patent/AU2001264629A1/en not_active Abandoned
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0817444A2 (en) * | 1996-07-01 | 1998-01-07 | Sun Microsystems, Inc. | System for context-dependent name resolution |
WO1998050863A1 (en) * | 1997-05-02 | 1998-11-12 | Whowhere? Inc. | An improved method for providing an internet protocol address with a domain name server |
EP0889418A2 (en) * | 1997-06-30 | 1999-01-07 | Sun Microsystems, Inc. | Abstract URL resolution via relocation service |
EP0959601A1 (en) * | 1998-05-21 | 1999-11-24 | Sun Microsystems, Inc. | A system and method for server selection for mirrored sites |
WO2000004458A1 (en) * | 1998-07-14 | 2000-01-27 | Massachusetts Institute Of Technology | Global document hosting system utilizing embedded content distributed ghost servers |
Non-Patent Citations (2)
Title |
---|
CARDELLINI V ET AL: "Dynamic load balancing on Web-server systems" IEEE INTERNET COMPUTING, MAY-JUNE 1999, IEEE, USA, vol. 3, no. 3, pages 28-39, XP002170537 ISSN: 1089-7801 * |
PUGH A M: "BLOWING AWAY WEB DELAYS" DATA COMMUNICATIONS, MCGRAW HILL. NEW YORK, US, vol. 28, no. 15, 21 October 1999 (1999-10-21), pages 30-34,36-38, XP000865033 ISSN: 0363-6399 * |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE10311247B4 (en) * | 2003-03-14 | 2008-01-31 | Inos Automationssoftware Gmbh | Portable device for detecting a position and dimensions of an object |
DE10311247B8 (en) * | 2003-03-14 | 2008-05-08 | Inos Automationssoftware Gmbh | Portable device for detecting a position and dimensions of an object |
WO2007111588A1 (en) * | 2006-03-28 | 2007-10-04 | Thomson Licensing | Centralized scheduler for content delivery network |
CN101406025B (en) * | 2006-03-28 | 2012-09-05 | 汤姆森许可贸易公司 | Centralization type scheduling device aiming at content transmission network |
GB2456026A (en) * | 2007-12-26 | 2009-07-01 | Contendo Inc | CDN balancing and sharing platform |
US20110299544A1 (en) * | 2010-06-04 | 2011-12-08 | David Lundgren | Method and system for managing bandwidth by a broadband gateway |
US9756124B1 (en) * | 2012-07-12 | 2017-09-05 | Juniper Networks, Inc. | Content delivery network referral |
WO2016041846A1 (en) * | 2014-09-17 | 2016-03-24 | British Telecommunications Public Limited Company | Content delivery network |
EP3451614A4 (en) * | 2017-01-22 | 2019-05-01 | Huawei Technologies Co., Ltd. | Dispatching method and device in content delivery network |
US10897406B2 (en) | 2017-01-22 | 2021-01-19 | Huawei Technologies Co., Ltd. | Scheduling method for content delivery network, and device |
Also Published As
Publication number | Publication date |
---|---|
AU2001264629A1 (en) | 2001-11-26 |
WO2001089172A3 (en) | 2002-04-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7185052B2 (en) | Meta content delivery network system | |
US12028427B2 (en) | Content delivery systems and methods | |
US8745240B2 (en) | Global load balancing on a content delivery network | |
EP1250785B1 (en) | A content distribution system for operating over an internetwork including content peering arrangements | |
US8806008B2 (en) | HTML delivery from edge-of-network servers in a content delivery network (CDN) | |
US9021112B2 (en) | Content request routing and load balancing for content distribution networks | |
Bartolini et al. | A walk through content delivery networks | |
US6553376B1 (en) | Efficient content server using request redirection | |
CA2720353C (en) | Handling long-tail content in a content delivery network (cdn) | |
EP0817444A2 (en) | System for context-dependent name resolution | |
CN105610930A (en) | Data optimization method based on DNS (Domain Name Server) | |
WO2001089172A2 (en) | Meta content delivery network system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
AK | Designated states |
Kind code of ref document: A3 Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A3 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 10276088 Country of ref document: US |
|
122 | Ep: pct application non-entry in european phase | ||
NENP | Non-entry into the national phase |
Ref country code: JP |