Patent ID: 12231518

DETAILED DESCRIPTION

Implementations of the present disclosure are directed to systems and methods for improved retrieval of content from CDNs and, in particular, to content centric localization of retrieval of content from CDNs. A rendezvous controller or system may be provided that receives information regarding an identification of content being requested and an estimated location of a device requesting the content. The request information may be provided by the requesting device or may be provided from a third party system. The rendezvous system may utilize the provided information to identify a server within a CDN from which the requested content may be retrieved. In one implementation, the rendezvous system may use the content identifier and the estimated location as inputs to a a repeatable hash function, the output of which may provide an identification of the server in the CDN to provide the content. Further, because the hash function is repeatable, subsequent requests for the same content form the same location may direct the requesting device to the same selected server. The server may cache the requested content upon the first request such that the content may be available to additional requests for the content. As requests are directed to the same servers for the same content, the likelihood that the content being requested is cached at the selected server increases. Steering requests to a server that may have the content cached may reduce the number of servers within the CDN with the same cached content, which is particularly advantageous for the highest requested content that might otherwise be overly redundantly cached in numerous locations. The rendezvous system may then return a corresponding domain name associated with the selected server and that can be subsequently submitted to a DNS for resolution to the IP address of the identified server. The reduction in redundancy of cached content on the servers of the CDN may improve the efficiency and throughput of the CDN in providing the hosted content.

In one example implementation, the rendezvous system is in communication with a content management system (CMS) accessible by a client device. In response to receiving a request for content from the client device, the CMS transmits a request to the rendezvous system including an identifier corresponding to the requested content and a location identifier corresponding to an estimated location of the client device. In an alternative arrangement, the client device may submit a request for content to the CMS which then provides a content identifier and/or a location identifier to the client device. The client device may then submit the content and location identifiers to the rendezvous system to receive an identification of the selected server from which a requested content may be provided.

Although other implementations are possible, in one example implementation, the CMS performs a lookup on customer data to retrieve the location identifier. In another example implementation, the CMS may determine a location identifier by performing a geolocation operation on an IP address or similar information corresponding to the client device. The IP address corresponding to the client device may be received in the content request as a source IP address. In still another implementation, the location identifier may be the IP address of the client device and the rendezvous system may perform the geolocation operation. The CMS may determine, based on the content and/or location identifier, a CDN from which the requested content may be retrieved by the client device. The CMS may then provide the content and location identifier to the rendezvous system associated with the selected CDN. In response to receiving each of the content and location identifier, the rendezvous system identifies a server of the CDN from which the requested content may be retrieved. More specifically, the rendezvous system may execute a hashing function or other repeatable function to determine an available server based on the content and geographic identifiers. Further, because the hash function is repeatable, subsequent requests for the same content form the same location may direct the requesting device to the same selected server of the CDN. The selected server may cache the requested content upon the first request such that the content may be available to additional requests for the content, that may be similarly steered to the selected server. As requests are directed to the same servers for the same content, the likelihood that the content being requested is cached at the selected server increases. In some instances, more than one server may be available to provide the requested content for the geographic area of the client device and the hashing function may identify one of the available servers to server the content.

The rendezvous system then returns a domain name to the client device (either directly or via the CMS) which may then submit the domain name to a domain name system (DNS) for resolution. For example, the client device may transmit the domain name to a DNS resolver that facilitates resolution of the domain name into an IP address corresponding to the identified server. Upon such resolution, the DNS resolver may return the IP address to the client device which, in turn, may initiate a session with the server and commence retrieval of the content.

In certain implementations of the present disclosure, content may be assigned to servers of the CDN using a consistent hash. As described below in further detail, such implementations enable the efficient distribution of content across servers of the CDN while improving the efficiency with which the CDN handles the addition and removal of servers from the CDN.

FIG.1Ais an example network environment100for distributing content to one or more users. Although illustrated inFIG.1Aas a content delivery network, it should be appreciated that aspects of the present disclosure may apply to any type of telecommunications network that utilizes network addressing (such as Internet Protocol (IP) addresses, media access control (MAC) addresses, domain names, etc.) for connecting an end user to one or more components of the network. For example, aspects of the disclosure may be utilized to connect a user of the network to a content server on which one or more content files is stored. Thus, although the CDN architecture is used throughout the document as the example network architecture through which aspects of the present disclosure may be applied; other network architectures and configurations are similarly contemplated.

In one implementation of the network environment100, a CDN102is communicably coupled to one or more access networks106. In general, the CDN102comprises one or more components configured to provide content to a user upon a request and an underlying IP network through which the request is received and the content is provided. The underlying IP network associated with the CDN servers may be any type IP-based communication network configured to transmit and receive communications through the network and may include any number and types of telecommunications components. In this manner, CDN-based components may be added to an existing IP-based communication network such that the components receive a request for content, retrieve the content from a storage device, and provide the content to the requesting device through the supporting IP network. For simplicity, the use of the term “CDN” throughout this disclosure refers to the combination of the one or more content servers and the underlying IP network for processing and transmitting communications, including one or more domain name architectures, unless otherwise noted.

In one embodiment, a client device104connects to the CDN102through one or more access networks106to request and receive content or content files from the CDN102. The access network106may be under the control of or operated/maintained by one or more entities, such as, for example, one or more Internet Service Providers (ISPs) that provide access to the CDN102. Thus, for example, the access network106may provide Internet access to a client device104. In addition, the access network106may include several connections to the IP network of the CDN102. For example, access network106includes access point120and access point122. Also, the client device104may be connected to any number of access networks106such that access to the CDN102may occur through another access network. In general, access to a CDN102(or underlying IP network associated with the CDN) may occur through any number of ingress ports to the CDN through any number of access networks.

The CDN102is capable of providing content to a client device104, which is generally any form of computing device, such as a personal computer, mobile device, tablet (e.g., iPad), or the like. Content may include, without limitation, videos, multimedia, images, audio files, text, documents, software, and other electronic resources. The client device104is configured to request, receive, process, and present content. In one implementation, the client device104includes an Internet browser application with which a link (e.g., a hyperlink) to a content item may be selected or otherwise entered, causing a request to be sent to a directory server110in the CDN102. In another example, client device104may be a gaming console or smart television through which files, videos, images, and the like may be viewed.

The CDN102may include a directory or authoritative server110that responds to the request by providing a network address (e.g., an IP address) where the content associated with the selected link can be obtained. In one implementation, the directory server110provides a domain name system (DNS) service, which resolves an alphanumeric domain name to an IP address. The directory server110resolves the link name (e.g., URL or other identifier) to an associated network address from which the client device104can retrieve the content. In some instances, the access network106may also include a DNS service. The directory server110may, in some instances, include several DNS servers arranged in a DNS architecture or system of servers to resolve domain names into IP addresses. For example,FIG.1Bis an example network environment150of an authoritative domain name server (DNS) of a DNS architecture154. The components of the network150are similar or the same as components discussed above with reference to the network100ofFIG.1A. For example, the network environment150includes a user computing device104, an access network106configured to provide access to a CDN for the computing device, and one or more DNS servers, discussed above.

As mentioned, the client device104may request content or a content file from the CDN102. In one example, the client device104provides a link name (e.g., URL or other identifier) associated with content provided by the CDN102. For example, client device104may provide a link name to a DNS resolver152associated with the access network106. The DNS resolver152associated with the access network106is sometimes known as the ISP resolver. In one example, the access network ISP resolver152has cached an IP address for the provided URL at which the content available through that URL may be obtained. In other words, the ISP resolver152may return an IP address of a device (such as a content server or other content-providing device of the CDN102) to the client device104to which the computing device may follow to access the content of the URL from the CDN.

However, while the ISP resolver152may be implemented to cache responses, the resolver often may not have a cached IP address for the provided domain name. In such cases, the DNS resolver152transmits a second DNS request to a DNS architecture154of the CDN102to receive an IP address at which the content file may be obtained. In general, the DNS architecture154provides a root node hierarchy of DNS resolvers that respond to DNS requests by either responding with the IP address associated with the provided domain name or directing the requesting device152through the architecture to the corresponding or proper DNS resolver within the architecture154. Through the DNS architecture154, the DNS request from the ISP resolver152is fulfilled (i.e., the IP address associated with the request is provided to the ISP resolver152). In turn, the ISP resolver152may cache the returned IP address for future requests received at the resolver and may provide the IP address to the client device104in response to the DNS request.

More particularly, when the ISP resolver152does not have a cached IP address for the requested content, the ISP resolver152transmits a DNS request to a root node156or root server of the DNS architecture154. The root node156may, in some instances, analyze the request and determine a type of URL included in the request. For example, the root node156may determine if the URL includes a “.com”, “.net”, “.org”, etc. as a part of the entered URL. The DNS architecture154may include a DNS resolver for each of the different types of URLs, such as a DNS resolver158for .org URL requests, a DNS resolver160for .net URL requests, a DNS resolver162for .com URL requests, and so on. Upon determining the type of URL requested, the root node156may return to the ISP resolver152a redirect to a corresponding DNS resolver within the architecture154.

The ISP resolver152may continue sending DNS requests to the DNS architecture154, working down the hierarchy of the DNS architecture154servers, until the DNS164-170corresponding to the received URL is located. In this manner, the ISP resolver152is directed to, for example, DNS server B166within the architecture154for the particular URL and, once the IP address corresponding to the URL is obtained, the ISP resolver152may cache and/or provide the IP address to the client device104. With this information, the computing device104accesses a device within the CDN102at the provided IP address and receives the requested content from the CDN102.

Returning toFIG.1A, the CDN102may include one or more edge servers112, which may cache content from another server to make it available in a more geographically or logically proximate location to the client device104. The edge server112may reduce network loads, optimize utilization of available capacity, lower delivery costs, and/or reduce content download time. The edge server112is configured to provide requested content to a requestor, which may be the client device104possibly via an intermediate device, for example, in the access network106. In one implementation, the edge server112provides the requested content that is locally stored in cache. In another implementation, the edge server112retrieves the requested content from another source, such as a media access server (MAS) (e.g., a content distribution server114or a content origin server116of a content provider network118). The content is then served to the client device104in response to the requests.

Client device104may also contact content management system (CMS)124of the content provider network118to receive further instructions or commands on accessing content from the CDN102. For example, content provider network118may utilize more than one CDN for providing content to requesting devices. The selection of the CDN to provide content to the client device104may be based on any number and type of criteria, such as location of the client device104, performance of the CDNs in the client device's location, a pricing structure for the content provider to use a CDN, constraints for the CDN established through a service provider agreement, and the like. Regardless of the business logic executed by the CMS124, the CMS124may select a CDN from available CDNs to provide the requested content to the client device104. In some instances, the client device104provides one or more identifiers to the CMS124for determining the CDN for the content. For example, the client device104may provide a geographic location indicator and an indicator of the requested content to the CMS124. In other examples, the CMS124may determine or estimate the client device104location, such as by accessing an IP address associated with the access network106and estimating the client device104location from a database of IP addresses and estimated locations. The CMS124may also estimate the requested content by extracting or accessing a content file indicator in a URL, hostname, or other portion of the request for the content. Regardless of the business logic executed by the CMS124to select a CDN102for the client device104, the CMS124may transmit an instruction or identification of the selected CDN102to the access network106or client device104. The client device104or access network106may then redirect the request for content to the selected or identified CDN to request the content from the selected CDN. Additional operations of the CMS124are discussed in more detail below.

Once the CDN102is selected by the CMS124, the client device104accesses the CDN to resolve the hostname or URL with the selected CDN102as described above. However, many DNS architectures154of CDNs102may have only limited information regarding the geographic location of the client device and/or the content that may be cached at the available content servers112of the CDN102such that the efficiency of the CDN102to cache content and direct requesting devices to the devices in which the content is cached is limited. For example, the DNS154may direct the client device104to access a first server112for the content that does not have the requested content cached while a second available server110has cached the requested content. Alternatively, popular content may be cached at multiple servers of the CDN102, consuming memory space within those servers that may be used for other content.

FIG.2is a block diagram of a network environment200for distributing content that utilizes a rendezvous system202for directing client devices104to connect to determined servers within the CDN102to provide content to the requesting device. Several components of the network environment100may be the same or similar to the components discussed above with reference toFIGS.1A and1B. For example, the environment200includes a client device104, which may be any suitable computing device configurable to request and receive content from one or more content delivery networks (CDNs). For example and without limitation, the client device104may be one of a laptop computer, a desktop computer, a tablet, a smartphone, a video game console, or any other similar computing device. The environment200may also include a CMS124of a content provider network118for communicating with the client device104to select a CDN from multiple available CDNs for providing content to the client device104, redirect the client device to contact the selected CDN102to transmit a DNS request, provide some content directly to the client device104(such as portals for accessing supported software or programs), and the like. A DNS resolver152and DNS architecture154is also included in the network environment200and operate as described above. CDN-A102is illustrated as the CDN selected by the CMS124for providing content to the client device104from multiple available CDNs.

In general, the CMS124may contact or otherwise communicate with the rendezvous system202to receive information on a particular content server or other content providing device of CDN-A102from which content may be provided to the client device104. The communication with the rendezvous system202may occur in response to receiving a content request from the client device104. For example and as illustrated inFIG.2, the client device104may transmit a content request to the CMS124based on interactions of the client device104with the content provider network118. In some instances, a user of the client device104may access a portal or program of the client device104that directs a content request to the CMS124. The content request may include various information related to the client device104and/or the requested content. For example, the content request may include an IP address associated with the client device104or the access network106through which the client device104is communicating with the CMS124. In another example, the content request may include a geographic location identifier of the client device104. Further, the content request may include some identifier associated with the requested content, such as a file name, a path name, a number identifier, and the like. In general, any identifier utilized by the content provider network118for identifying or storing the content may be used and transmitted by the client device104in the content request.

The CMS124, upon receiving the content request, may determine a CDN102from which the content is available to the client device104. In one example, the CMS124may execute logic or other operations to determine the CDN102. Such logic may consider the client device104location indicator and/or the content request indicator, as well as other business considerations discussed above. In some instances, the CMS124may select a CDN102that includes a corresponding rendezvous system202. The rendezvous system202may aid the client device104is accessing a content server or other content-providing device of the selected CDN102to receive the requested content. In the example illustrated inFIG.2, the CMS124may select, based on one or more business logic rules, to direct the client device104to CDN-A102from a plurality of available CDNs to provide the content. Rendezvous system202may be associated with CDN-A102and the CMS124may consult the rendezvous system202for directing the client device104to access a particular server (such as server A204) of a plurality of available servers204-208of the CDN-A102to provide the requested content to the client device104.

More particularly, CMS124may transmit a server request to the rendezvous system202associated with the selected CDN102. The server request sent to the rendezvous system202may include information associated with the content request received at the CMS124, such as an identification of the requested content (such as a content file name or other identifier) and/or an estimated geographic location of the client device104. As described above, the location identifier may generally be any value corresponding to a geographic location or area. In certain implementations, the geographic location or area may generally correspond to a geographic location or area associated with the client device104and/or a user of the client device. Such information may include, without limitation, one or more of an address, a zip code, a county, a city, an airport code, one or more coordinates (e.g., longitude and latitude coordinates), or any other information that may describe a geographic location or region. In one example implementation, the location identifier may be an IP address or similar network address of the client device104. In such implementations, the location of the client device104may be obtained using a geolocation algorithm or lookup that converts the IP address to a physical location suitable for identifying a geographically proximal (or similarly favored) CDN.

Although described primarily as corresponding to a location of the client device104, it should be appreciated that the location identifier may correspond to any location. For example, instead of corresponding to a location of the client device104, the location identifier may instead correspond to a proxy computing device, a location chosen by the CMS124, or any other suitable location.

In response to receiving the request from the CMS124, the rendezvous system202may determine one or more servers204-208of the CDN102from which the content may be accessed or provided to the client device104. In certain implementations, identifying the servers may include determining which servers202-208of the CDN-A in the geographic location of the client device104may provide the requested content, either from cache or from the content provider network. For example, the rendezvous system106may access location data from a location database210that correlates location information in the form received from the CMS124to the CDN-A102. The rendezvous system202may then perform a lookup in the location data210using the location information to determine geographically suitable servers204-208from which the content requested by the client device104may be retrieved. For purposes of the current example, it is assumed that the foregoing process results in the identification of servers204-208of CDN-A102as the most geographically suitable.

In addition, the rendezvous system202may further generate a server identifier for a specific server204within the identified CDN102area for providing the content. In the current example, CDN-A102includes multiple servers identified as SERVER-A to SERVER-C204-208. However, any number of servers may be available for providing the content to the client device104from CDN-A102. In certain implementations, the rendezvous system202may have access to CDN content data212for the content available via CDN-A102associated with the rendezvous system202. The CDN content data212may include, for each piece of content, information for identifying those servers204-208in the area of the client device104from which the content may be requested or provided. In addition, the rendezvous system202may select, from the group of available servers204-208, a particular server204to provide the content to the client device104. For example, the CDN content data212may include a list of content identifiers and, for each content identifier, a corresponding server index (or information from which the server index may be obtained) indicating from which server204of a CDN102the content may be retrieved. A specific example of how the particular server204is determined via a consistent hash function is discussed below in further detail. Regardless of the method used to identify a server204of CDN-A102, for purposes of the current example, it is assumed that the rendezvous system202determines that Server A204is the preferred server from which the content is to be retrieved and, as a result, obtains a corresponding server identifier for Server A204.

After identifying a server, the rendezvous system202may return a domain name to the CMS104corresponding to the identified server. The CMS124may then return the domain name to the client device104. In one specific example, the domain name may be of the form “<server>.<location>.<domain>”, where <server> is a server identifier corresponding to the identified server (e.g., “serverA”), <location> is an identifier of the geographic location associated with the client device104and the CDN portion containing the server (e.g. “Denver”), and <domain> is a domain (e.g., “foo.com”) associated with the DNS architecture154for resolving domain names generated by the rendezvous system202. So, for example, a domain name of “serverA.Denver.foo.com” may be returned to the client device104from the CMS124as received from the rendezvous system202if the content is to be retrieved from Server A204of CDN-A102.

After receiving the domain name from the CMS124, the client device104may provide the domain name to a DNS resolver152in a DNS request, as described above. In some instances, the DNS resolver152may forward the DNS request to the DNS architecture154to obtain a corresponding IP address for server A204. To resolve the DNS request, the DNS architecture154may communicate or access a rendezvous lookup table214including entries that correspond location, server identifier, and a particular IP address of a server of the CDN-A102. The information included in the rendezvous lookup table214may be provided to the DNS architecture154by the rendezvous system202to correspond server identifiers with IP addresses of servers of the CDN102. In this manner, the rendezvous system202may control which servers204-208of the CDN102are associated with the particular server identifiers provided by the rendezvous system202in response to a query from the CMS124. The particular IP address for the server identified by the server identifier is then provided to the client device104. In some instances, the DNS architecture154may provide a plurality of IP addresses of multiple servers of the CDN102with some indication of a preference for one server over another. For example, the DNS architecture154may provide a first IP address for server A204, a second IP address for server B206, a weighted value of x associated with the first IP address, and a weighted value of y associated with the second IP address, with x being a larger weighted value than y. The second IP address may indicate a backup server for requesting content if the first server associated with the first IP address cannot provide the content. The weighted values may provide further instructions to the client device104for accessing servers204-208of the CDN102.

The client device104may then initiate a session (e.g., a hypertext terminal protocol (http) or similar session) with server A204to retrieve the requested content. In cases where the content is cached or otherwise stored at server A204, server A may begin transmitting the content to the client device104. If, on the other hand, server A204does not currently store the requested content, server A may retrieve and cache the content consistent with the particular content distribution and caching techniques implemented in the CDN102as described above.

Through the network environment200ofFIG.2, the client device104may be pushed to request content from a particular server204of the CDN102. As content from the CDN102is cached at the servers204-208upon one or more requests for the content, directing client devices104to particular servers may improve the caching function of the CDN. More particularly, client devices104requesting the same content may be directed to the same servers such that the content may be cached at a few select servers, freeing up caching space on other servers of the CDN102to cache other content. A repeatable process for directing client devices104requesting the same content to the same server or servers may therefore improve the efficiency of the CDN102to provide said content to the client devices104.

FIG.3is a second example network environment300including a second rendezvous system302for processing requests for content available through a CDN102. Similar to the network environment200ofFIG.2, the network environment300ofFIG.3includes a client device140in communication with a CMS124. The CMS124is configured to present and/or manage requests for content received from the client device140. In this implementation, the CMS124again determines which CDN of multiple CDNs for which the requested content may be provided to the client device140. For example, CMS124may select CDN-A102from a plurality of available CDNs to provide the content. In response to the request for content received at the CMS124, the CMS may return to the client device104a redirect instruction to access the rendezvous system302of the environment300. In other words, rather than the CMS124accessing the rendezvous system302to obtain the server identifier of the CDN102as above, the client device104may be redirected, based on information provided by the CMS124, to the rendezvous system302. In one instance, the redirect instructions may include a content identifier, a CDN identifier of the selected CDN, an IP address or other network address of the rendezvous system302, a geographic location identifier of an estimated location of the client device104, and/or other information for redirecting the client device104.

In response to receiving the redirect instruction from the CMS124, the client device104may transmit a server identification request to the rendezvous system302to identify the particular server within the CDN102from which the requested content may be accessed. In one example, the server identification request, similar to above, may include an identifier of the requested content and a geographic location indicator of the client device104. The rendezvous system302then generates and returns a domain name to the client device104. As previously discussed, the domain name may include, among other things, identifiers corresponding to a specific server204of a specific CDN102from which the requested content may be retrieved and may be generated by the rendezvous system302based on one or more of location data210and/or CDN data212, as previously discussed above. In addition, the rendezvous system302may execute a hashing function or other similar algorithm to select the server204of the CDN102for providing the requested content.

The client device104may then submit the received domain name to a DNS resolver152and/or the DNS architecture154to resolve the domain name to an IP address of the server204from which the content may be retrieved, as described. The client device104may then connect to the server204and request the content.

In still another instance, one or more of the functions of the rendezvous system202,302may be performed by the CMS124. For example, the rendezvous system302may provide the hashing function executed to determine the particular server204of the available servers204-208of the CDN102. The CMS124may then execute the hashing function to obtain the server identifier for the selected server and provide the server identifier accordingly. In addition, the CMS124may be given access to location database210and/or CDN database212to determine the available servers of the CDN102for providing the content to the client device104, based on the content identifier and/or the geographic location identifier of the client device104received at the CMS124.

FIG.4is a flow chart illustrating a method400for processing requests for content available through a CDN102. In one instance, the operations of the method400may be executed by the rendezvous system202,302of the network environment200,300described above. In other instances, other systems or devices of the environments discussed above may execute one or more of the operations. For example, CMS124, DNS architecture154, and/or the client device104may the operations. The operations may also be executed through a software program, one or more hardware components, or a combination of software programs and hardware components.

Beginning in operation402, the rendezvous system202may obtain CDN architecture data from the CDN database212. In particular, the rendezvous system202may determine one or more servers available in a particular location serviced by the CDN-A102. For example, the rendezvous system202may determine that servers A-C204-208of CDN-A102may be available to provide content to requesting devices within the a particular geographic location, such as a metro area. Other locations or metro areas may be serviced by the CDN-A102and may include more or fewer content servers204-208. For example, a large metro area may include 20 servers to provide content to requesting devices within the metro, while a smaller metro area may include fewer than 5 servers to provide content servers for devices within the small metro. In general, more servers may be available to provide content in geographic areas with more potential requesting devices or users.

In operation404, the rendezvous system202may generate a server identification and location table from the CDN architecture data associated with a particular location or metro area of the CDN102. Using the example illustrated inFIG.2, the CDN-A102may include three servers (namely server A-C204-208) for providing content to requesting devices in a particular geographic area. The geographic location and the three servers204-208available to provide content may be obtained from the CDN database212by the rendezvous system202and a table associating the three servers204-208and the geographic location may be generated. In a similar manner, other geographic locations and the identification of a number of servers of the location may also be included in the table by the rendezvous system202. In one particular example, the servers204-208available in a particular location may be noted in the table by a server ID value that acts as a placeholder value for the server in relation to the number of servers available in the location. For example, servers204-208of the CDN102may be included in the table with server IDs as discussed above, such as “serverA.Denver.foo.com”. An additional entry may also be included in the server ID/location table or may be included in a separate table. The additional entry may associate the generated server IDs of the table with a network address or other network identifier, such as an IP address associated with each of the noted server IDs. In some instances, the IP address for one or more servers of the table may be updated in the table as available servers of the CDN102are brought online or removed. For example, an IP address of a redundant server may be included in the table upon a failure of a server of the CDN102to redirect traffic from the failed server to the redundant server.

In operation406, the rendezvous system202may provide, to the DNS architecture154, access to the generated server ID/location table or to the information included in the table. In one instance, the rendezvous system202may maintain the rendezvous table in a database214and notify the DNS architecture154of the presence of the table in the database214. In another example, the rendezvous system202may provide the table to the DNS architecture154, which may store the table in the rendezvous table database214. Updates to the table may occur in a similar manner in which the rendezvous system202may provide the updates to the DNS architecture154that may update the rendezvous table database214accordingly. Regardless of the database used, the DNS architecture154may be provided access to the information contained in the rendezvous table214such that the DNS architecture154may respond with an IP address of a server204of the CDN102based on a DNS request provided by a requesting device104. The DNS request may include a server ID as noted above from which the DNS architecture154may access a corresponding IP address for the target server of the CDN102.

In operation408, the rendezvous system202may receive, from a requesting device such as the CMS124or client device104, a request for content that includes an identifier of the requested content and an identifier of a location of the client device104. As described above, the CMS124may provide the content request based on information provided to the CMS124from the client device104. Alternatively, the client device104may be redirected to provide the rendezvous system202with the content request. The content identifier may be any alphanumeric or other value associated with the requested content and the location identifier may be an estimated location of a destination device for receiving the content. In operation410, the rendezvous system202may execute a hashing function using the content identifier and/or the location identifier to generate a server ID from which the content may be provided to the client device104. For example, the rendezvous system202may utilize the CDN data212to determine the number of servers available for the particular location identified in the location identifier. The number of servers for the particular location may be a first input to the hashing function. The hashing function may also use the content identifier to generate a server ID from the number of available servers for the location of the client device104.

In one specific example, the rendezvous system202may use a distributed consistent hashing scheme. Consistent hashing is based on mapping each object (here, either servers of the CDN102or content available through the CDN) to a location on the edge of a circle or ring, where each location on the ring corresponds to a value in a hash key space defined by the range of outcomes of a hashing function. For example, in certain implementations, an n-bit hashing function may generate a hash ranging from 0 to 2{circumflex over ( )}n−1 and, as a result, the corresponding hash key space may include 2{circumflex over ( )}n locations. The location of a given object in the hash key space is then determined by hashing a key associated with the object. So, for example, a key for a given piece of content may be the content itself or other data associated with the content. Similarly, a key for a server of the CDN may be an identifier associated with the server or some other data associated with the server, such as the server's IP address or name.

To determine from which server a given piece of content is to be retrieved, the location of the content within the hash key space is identified. The content is then assigned to the next server in a particular direction (e.g., clockwise or counter-clockwise) about the circle. As a result, a given server provides all content located between itself and the previous server on the circle opposite the direction of travel used in the consistent hash. The foregoing process of assigning content to a server be expressed as:
serverID=hash(contentkey)%N
where N is the total number of servers for the CDN, hash ( ) is a hashing function, contentkey is a key associated with the content (which may be but is not limited to the content itself) and serverID is a numerical identifier ranging from 0 to N assigned to a server of the CDN. In response to a server being added or removed from the CDN (e.g., a change in the value of N in the above formula), the serverID for each piece of content may be recalculated and the content may be redistributed or reassigned within the CDN according to the new mapping. Accordingly, if a server becomes unavailable (for example, because the server is disconnected, fails, or is removed from the CND) then the points it maps to will be removed and remapped to other servers. Similarly, adding a new server between two servers would take on at least a portion of the points mapped to the next server.

As noted, each piece of available content from the CDN102for an area may be associated with a particular serverID corresponding to the server on which the content is stored. Such information may be stored, for example, as part of the CDN content data212accessible by the rendezvous system202. In other implementations, other data from which the server may be identified may be stored and accessible by the rendezvous system202such that the rendezvous system may dynamically identify the particular server from which content may be retrieved. The rendezvous system202may then calculate a serverID based on the number of servers identified in the CDN data212for the particular location of the client device104.

In implementations of the present disclosure, identification of a particular server from which to obtain content may be deterministic. In other words, requests for the same content and including location identifiers that are resolved to the same server204always result in the requesting device being directed to the same server204. In this manner, content may be cached at determined servers, based on the requested content, to reduce unnecessary caching of content across multiple servers within an area serviced by the CDN102. This may open up caching space for other content to be cached, improving the efficiency of the caching scheme of the CDN102.

In operation412, the rendezvous system202may transmit the determined server ID to the requesting device from which the content request was received. For example, the rendezvous system202may transmit the server ID to the CMS124or the client device104. The server ID may be, in some instances, included in a domain name, such as “serverA.Denver.foo.com”. As described above, this domain name may be used by the client device104as a portion of a DNS request to the DNS architecture154to obtain an IP address or other network address for the selected server204of the CDN102for providing the content.

In certain implementations of the present disclosure, the client device104may receive multiple domain names and/or IP addresses in response to a content request. For example, in one implementation, the rendezvous system202may provide a first domain name corresponding to a primary server for retrieving requested content and one or more second domain names corresponding to a backup server. In implementations in which content is distributed via a consistent hashing scheme, for example, the backup server may be the next server in the consistent hash. Multiple IP addresses may also be provided to the client device104when resolving a domain name received from the rendezvous system202. In such cases, the DNS architecture154may be configured to provide multiple IP addresses in response to receiving a domain name identifying a particular server of a CDN102.

FIG.5is a block diagram illustrating an example of a computing device or computer system500which may be used in implementing the embodiments of the network disclosed above. In particular, the computing device ofFIG.5is one embodiment of the server or other networking component that performs one of more of the operations described above. The computer system (system) includes one or more processors502-506. Processors502-506may include one or more internal levels of cache (not shown) and a bus controller or bus interface unit to direct interaction with the processor bus512. Processor bus512, also known as the host bus or the front side bus, may be used to couple the processors502-506with the system interface514. System interface514may be connected to the processor bus512to interface other components of the system500with the processor bus512. For example, system interface514may include a memory controller518for interfacing a main memory516with the processor bus512. The main memory516typically includes one or more memory cards and a control circuit (not shown). System interface514may also include an input/output (I/O) interface520to interface one or more I/O bridges or I/O devices with the processor bus512. One or more I/O controllers and/or I/O devices may be connected with the I/O bus526, such as I/O controller528and I/O device530, as illustrated.

I/O device530may also include an input device (not shown), such as an alphanumeric input device, including alphanumeric and other keys for communicating information and/or command selections to the processors502-506. Another type of user input device includes cursor control, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to the processors502-506and for controlling cursor movement on the display device.

System500may include a dynamic storage device, referred to as main memory516, or a random access memory (RAM) or other computer-readable devices coupled to the processor bus512for storing information and instructions to be executed by the processors502-506. Main memory516also may be used for storing temporary variables or other intermediate information during execution of instructions by the processors502-506. System500may include a read only memory (ROM) and/or other static storage device coupled to the processor bus512for storing static information and instructions for the processors502-506. The system set forth inFIG.5is but one possible example of a computer system that may employ or be configured in accordance with aspects of the present disclosure.

According to one embodiment, the above techniques may be performed by computer system500in response to processor504executing one or more sequences of one or more instructions contained in main memory516. These instructions may be read into main memory516from another machine-readable medium, such as a storage device. Execution of the sequences of instructions contained in main memory516may cause processors502-506to perform the process steps described herein. In alternative embodiments, circuitry may be used in place of or in combination with the software instructions. Thus, embodiments of the present disclosure may include both hardware and software components.

A machine readable medium includes any mechanism for storing or transmitting information in a form (e.g., software, processing application) readable by a machine (e.g., a computer). Such media may take the form of, but is not limited to, non-volatile media and volatile media. Non-volatile media includes optical or magnetic disks. Volatile media includes dynamic memory, such as main memory516. Common forms of machine-readable medium may include, but is not limited to, magnetic storage medium (e.g., floppy diskette); optical storage medium (e.g., CD-ROM); magneto-optical storage medium; read only memory (ROM); random access memory (RAM); erasable programmable memory (e.g., EPROM and EEPROM); flash memory; or other types of medium suitable for storing electronic instructions.

Embodiments of the present disclosure include various steps, which are described in this specification. The steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the steps. Alternatively, the steps may be performed by a combination of hardware, software and/or firmware.

Various modifications and additions can be made to the exemplary embodiments discussed without departing from the scope of the present invention. For example, while the embodiments described above refer to particular features, the scope of this invention also includes embodiments having different combinations of features and embodiments that do not include all of the described features. Accordingly, the scope of the present invention is intended to embrace all such alternatives, modifications, and variations together with all equivalents thereof.