Patent Description:
The Internet and the World Wide Web (the 'Web") are ubiquitous and easily accessible using numerous possible wired or wireless computing devices. Content providers (publishers) now use the Internet (and, particularly, the Web) to provide all kinds of content to numerous users throughout the world through any number of platforms. In order to offload the job of serving some or all of its content, many content providers now operate or subscribe to content delivery networks (CONs). Provider content can be served to clients from the CDN (e.g.,, from one or more content servers in the CDN) instead of from the content provider's server(s). In a caching CDN, content may also be locally cached for delivery by the CDN servers. Having content cached enhances the performance of the CDN because the content does not have to be retrieved from origin servers or other locations, which are less efficient than edge servers in providing content.

Numerous forms of content may be served from the CDN. For example, television shows and movies may now be accessed from any number of Web sites or through applications running on smart TVs, tablets, smart phones, etc., and the shows and movies may be served from the CDN. Print newspapers have migrated to the Web and provide portals through which clients operating some form of computing device (e.g., PC, smart phone, or tablet), with a browser may access numerous forms of content, such as short video clips, articles, images, and audio tracks. Software updates and patches, once provided on disc and mailed to recipients, are now routinely distributed to devices from a CDN through one or more network connections and devices.

In conventional CDN systems, a content management system (CMS) may receive a request for a particular piece of content from a user/client device. For example, a user may select a movie, television show, or software update from a list or interface provided by the CMS. In response, the CMS returns a domain name identifying a CDN from which the content may be retrieved. In this manner, the CMS may select from more than one CDN for providing the requested content to the client device. The client device, upon receiving the domain name for the selected CDN, then provides the domain name to a domain name system (DNS) resolver that subsequently submits the request to one or more DNS servers, including a name server of the DNS, that resolves the domain name to a corresponding Internet Protocol (IP) address. The IP address is then returned to the client device which initiates a session with the server associated with the returned IP address to retrieve the requested content.

Such conventional CDN systems have various inefficiencies related to the selection of servers from which content is to be provided. For example, if a content provider uses multiple CDNs, the content provider (or more specifically the CMS) is generally responsible for selecting from which CDN the content is to be provided. However, because the content provider is generally privy to only limited information regarding the performance and characteristics of the CDNs available to it, the content provider may select a non-optimal CDN to provide content. Similarly, the identification of a particular server or other content-providing device by the DNS may also be inefficient. For example, the name server may be configured to select from one of many available servers based on various performance criteria. In one example, the server may be selected based on lowest return trip time, which is generally a function of geographic proximity between the server and the client device. However, in conventional systems, the name server may have only limited information regarding the geographic location of the client device and/or the content that may be cached at the available servers. For example, the DNS may direct the client device to access a first server for the content that does not have the requested content cached while a second available server has cached the requested content. Without knowledge of the cached content at each server or the correct geographic location of the client device, inefficiencies in providing content to requesting devices may be introduced. Accordingly, to the extent the DNS resolver and client device may be more efficiently served by particular CDNs or particular components within a CDN, such efficiencies are foregone.

It is with these observations in mind, among others, that aspects of the present disclosure were conceived.

<CIT>; "Systems for accelerating content delivery via DNS overriding" which discloses a system for accelerating content delivery via DNS overriding which may comprise a network storage device communicatively coupled to a network and storing a routing table for a CDN;.

<CIT>; "CUSTOMIZED DOMAIN NAMES IN A CONTENT DELIVERY NETWORK (CDN)" which discloses that a first domain name is obtained at a cache server in CDN, the first domain name being associated with a client request, wherein a domain name server generates a second domain name based on the first domain name; and.

<CIT>; "System for Transforming Mobile App Into Addressable Network for Stateless Access" which discloses that a navigation controller navigates to the first state of the first mobile application within a device. A content scraper extracts content from the first state and identifies forward links to corresponding additional states of the first mobile application.

The invention is defined in the appended independent claims.

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> is an example network environment <NUM> for distributing content to one or more users. Although illustrated in <FIG> as 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 environment <NUM>, a CDN <NUM> is communicably coupled to one or more access networks <NUM>. In general, the CDN <NUM> comprises 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 device <NUM> connects to the CDN <NUM> through one or more access networks <NUM> to request and receive content or content files from the CDN <NUM>. The access network <NUM> may 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 CDN <NUM>. Thus, for example, the access network <NUM> may provide Internet access to a client device <NUM>. In addition, the access network <NUM> may include several connections to the IP network of the CDN <NUM>. For example, access network <NUM> includes access point <NUM> and access point <NUM>. Also, the client device <NUM> may be connected to any number of access networks <NUM> such that access to the CDN <NUM> may occur through another access network. In general, access to a CDN <NUM> (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 CDN <NUM> is capable of providing content to a client device <NUM>, 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 device <NUM> is configured to request, receive, process, and present content. In one implementation, the client device <NUM> includes 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 server <NUM> in the CDN <NUM>. In another example, client device <NUM> may be a gaming console or smart television through which files, videos, images, and the like may be viewed.

The CDN <NUM> may include a directory or authoritative server <NUM> that 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 server <NUM> provides a domain name system (DNS) service, which resolves an alphanumeric domain name to an IP address. The directory server <NUM> resolves the link name (e.g., URL or other identifier) to an associated network address from which the client device <NUM> can retrieve the content. In some instances, the access network <NUM> may also include a DNS service. The directory server <NUM> may, 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> is an example network environment <NUM> of an authoritative domain name server (DNS) of a DNS architecture <NUM>. The components of the network <NUM> are similar or the same as components discussed above with reference to the network <NUM> of <FIG>. For example, the network environment <NUM> includes a user computing device <NUM>, an access network <NUM> configured to provide access to a CDN for the computing device, and one or more DNS servers, discussed above.

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

However, while the ISP resolver <NUM> may 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 resolver <NUM> transmits a second DNS request to a DNS architecture <NUM> of the CDN <NUM> to receive an IP address at which the content file may be obtained. In general, the DNS architecture <NUM> provides 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 device <NUM> through the architecture to the corresponding or proper DNS resolver within the architecture <NUM>. Through the DNS architecture <NUM>, the DNS request from the ISP resolver <NUM> is fulfilled (i.e., the IP address associated with the request is provided to the ISP resolver <NUM>). In turn, the ISP resolver <NUM> may cache the returned IP address for future requests received at the resolver and may provide the IP address to the client device <NUM> in response to the DNS request.

More particularly, when the ISP resolver <NUM> does not have a cached IP address for the requested content, the ISP resolver <NUM> transmits a DNS request to a root node <NUM> or root server of the DNS architecture <NUM>. The root node <NUM> may, in some instances, analyze the request and determine a type of URL included in the request. For example, the root node <NUM> may determine if the URL includes a ". org", etc. as a part of the entered URL. The DNS architecture <NUM> may include a DNS resolver for each of the different types of URLs, such as a DNS resolver <NUM> for. org URL requests, a DNS resolver <NUM> for. net URL requests, a DNS resolver <NUM> for. com URL requests, and so on. Upon determining the type of URL requested, the root node <NUM> may return to the ISP resolver <NUM> a redirect to a corresponding DNS resolver within the architecture <NUM>.

The ISP resolver <NUM> may continue sending DNS requests to the DNS architecture <NUM>, working down the hierarchy of the DNS architecture <NUM> servers, until the DNS <NUM>-<NUM> corresponding to the received URL is located. In this manner, the ISP resolver <NUM> is directed to, for example, DNS server B <NUM> within the architecture <NUM> for the particular URL and, once the IP address corresponding to the URL is obtained, the ISP resolver <NUM> may cache and/or provide the IP address to the client device <NUM>. With this information, the computing device <NUM> accesses a device within the CDN <NUM> at the provided IP address and receives the requested content from the CDN <NUM>.

Returning to <FIG>, the CDN <NUM> may include one or more edge servers <NUM>, which may cache content from another server to make it available in a more geographically or logically proximate location to the client device <NUM>. The edge server <NUM> may reduce network loads, optimize utilization of available capacity, lower delivery costs, and/or reduce content download time. The edge server <NUM> is configured to provide requested content to a requestor, which may be the client device <NUM> possibly via an intermediate device, for example, in the access network <NUM>. In one implementation, the edge server <NUM> provides the requested content that is locally stored in cache. In another implementation, the edge server <NUM> retrieves the requested content from another source, such as a media access server (MAS) (e.g., a content distribution server <NUM> or a content origin server <NUM> of a content provider network <NUM>). The content is then served to the client device <NUM> in response to the requests.

Client device <NUM> may also contact content management system (CMS) <NUM> of the content provider network <NUM> to receive further instructions or commands on accessing content from the CDN <NUM>. For example, content provider network <NUM> may utilize more than one CDN for providing content to requesting devices. The selection of the CDN to provide content to the client device <NUM> may be based on any number and type of criteria, such as location of the client device <NUM>, 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 CMS <NUM>, the CMS <NUM> may select a CDN from available CDNs to provide the requested content to the client device <NUM>. In some instances, the client device <NUM> provides one or more identifiers to the CMS <NUM> for determining the CDN for the content. For example, the client device <NUM> may provide a geographic location indicator and an indicator of the requested content to the CMS <NUM>. In other examples, the CMS <NUM> may determine or estimate the client device <NUM> location, such as by accessing an IP address associated with the access network <NUM> and estimating the client device <NUM> location from a database of IP addresses and estimated locations. The CMS <NUM> may 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 CMS <NUM> to select a CDN <NUM> for the client device <NUM>, the CMS <NUM> may transmit an instruction or identification of the selected CDN <NUM> to the access network <NUM> or client device <NUM>. The client device <NUM> or access network <NUM> may then redirect the request for content to the selected or identified CDN to request the content from the selected CDN. Additional operations of the CMS <NUM> are discussed in more detail below.

Once the CDN <NUM> is selected by the CMS <NUM>, the client device <NUM> accesses the CDN to resolve the hostname or URL with the selected CDN <NUM> as described above. However, many DNS architectures <NUM> of CDNs <NUM> may have only limited information regarding the geographic location of the client device and/or the content that may be cached at the available content servers <NUM> of the CDN <NUM> such that the efficiency of the CDN <NUM> to cache content and direct requesting devices to the devices in which the content is cached is limited. For example, the DNS <NUM> may direct the client device <NUM> to access a first server <NUM> for the content that does not have the requested content cached while a second available server <NUM> has cached the requested content. Alternatively, popular content may be cached at multiple servers of the CDN <NUM>, consuming memory space within those servers that may be used for other content.

<FIG> is a block diagram of a network environment <NUM> for distributing content that utilizes a rendezvous system <NUM> for directing client devices <NUM> to connect to determined servers within the CDN <NUM> to provide content to the requesting device. Several components of the network environment <NUM> may be the same or similar to the components discussed above with reference to <FIG> and <FIG>. For example, the environment <NUM> includes a client device <NUM>, 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 device <NUM> may be one of a laptop computer, a desktop computer, a tablet, a smartphone, a video game console, or any other similar computing device. The environment <NUM> may also include a CMS <NUM> of a content provider network <NUM> for communicating with the client device <NUM> to select a CDN from multiple available CDNs for providing content to the client device <NUM>, redirect the client device to contact the selected CDN <NUM> to transmit a DNS request, provide some content directly to the client device <NUM> (such as portals for accessing supported software or programs), and the like. A DNS resolver <NUM> and DNS architecture <NUM> is also included in the network environment <NUM> and operate as described above. CDN-A <NUM> is illustrated as the CDN selected by the CMS <NUM> for providing content to the client device <NUM> from multiple available CDNs.

In general, the CMS <NUM> may contact or otherwise communicate with the rendezvous system <NUM> to receive information on a particular content server or other content providing device of CDN-A <NUM> from which content may be provided to the client device <NUM>. The communication with the rendezvous system <NUM> may occur in response to receiving a content request from the client device <NUM>. For example and as illustrated in <FIG>, the client device <NUM> may transmit a content request to the CMS <NUM> based on interactions of the client device <NUM> with the content provider network <NUM>. In some instances, a user of the client device <NUM> may access a portal or program of the client device <NUM> that directs a content request to the CMS <NUM>. The content request may include various information related to the client device <NUM> and/or the requested content. For example, the content request may include an IP address associated with the client device <NUM> or the access network <NUM> through which the client device <NUM> is communicating with the CMS <NUM>. In another example, the content request may include a geographic location identifier of the client device <NUM>. 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 network <NUM> for identifying or storing the content may be used and transmitted by the client device <NUM> in the content request.

The CMS <NUM>, upon receiving the content request, may determine a CDN <NUM> from which the content is available to the client device <NUM>. In one example, the CMS <NUM> may execute logic or other operations to determine the CDN <NUM>. Such logic may consider the client device <NUM> location indicator and/or the content request indicator, as well as other business considerations discussed above. In some instances, the CMS <NUM> may select a CDN <NUM> that includes a corresponding rendezvous system <NUM>. The rendezvous system <NUM> may aid the client device <NUM> is accessing a content server or other content-providing device of the selected CDN <NUM> to receive the requested content. In the example illustrated in <FIG>, the CMS <NUM> may select, based on one or more business logic rules, to direct the client device <NUM> to CDN-A <NUM> from a plurality of available CDNs to provide the content. Rendezvous system <NUM> may be associated with CDN-A <NUM> and the CMS <NUM> may consult the rendezvous system <NUM> for directing the client device <NUM> to access a particular server (such as server A <NUM>) of a plurality of available servers <NUM>-<NUM> of the CDN-A <NUM> to provide the requested content to the client device <NUM>.

More particularly, CMS <NUM> may transmit a server request to the rendezvous system <NUM> associated with the selected CDN <NUM>. The server request sent to the rendezvous system <NUM> may include information associated with the content request received at the CMS <NUM>, 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 device <NUM>. 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 device <NUM> and/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 device <NUM>. In such implementations, the location of the client device <NUM> may 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 device <NUM>, it should be appreciated that the location identifier may correspond to any location. For example, instead of corresponding to a location of the client device <NUM>, the location identifier may instead correspond to a proxy computing device, a location chosen by the CMS <NUM>, or any other suitable location.

In response to receiving the request from the CMS <NUM>, the rendezvous system <NUM> may determine one or more servers <NUM>-<NUM> of the CDN <NUM> from which the content may be accessed or provided to the client device <NUM>. In certain implementations, identifying the servers may include determining which servers <NUM>-<NUM> of the CDN-A in the geographic location of the client device <NUM> may provide the requested content, either from cache or from the content provider network. For example, the rendezvous system <NUM> may access location data from a location database <NUM> that correlates location information in the form received from the CMS <NUM> to the CDN-A <NUM>. The rendezvous system <NUM> may then perform a lookup in the location data <NUM> using the location information to determine geographically suitable servers <NUM>-<NUM> from which the content requested by the client device <NUM> may be retrieved. For purposes of the current example, it is assumed that the foregoing process results in the identification of servers <NUM>-<NUM> of CDN-A <NUM> as the most geographically suitable.

In addition, the rendezvous system <NUM> may further generate a server identifier for a specific server <NUM> within the identified CDN <NUM> area for providing the content. In the current example, CDN-A <NUM> includes multiple servers identified as SERVER-A to SERVER-C <NUM>-<NUM>. However, any number of servers may be available for providing the content to the client device <NUM> from CDN-A <NUM>. In certain implementations, the rendezvous system <NUM> may have access to CDN content data <NUM> for the content available via CDN-A <NUM> associated with the rendezvous system <NUM>. The CDN content data <NUM> may include, for each piece of content, information for identifying those servers <NUM>-<NUM> in the area of the client device <NUM> from which the content may be requested or provided. In addition, the rendezvous system <NUM> may select, from the group of available servers <NUM>-<NUM>, a particular server <NUM> to provide the content to the client device <NUM>. For example, the CDN content data <NUM> may 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 server <NUM> of a CDN <NUM> the content may be retrieved. A specific example of how the particular server <NUM> is determined via a consistent hash function is discussed below in further detail. Regardless of the method used to identify a server <NUM> of CDN-A <NUM>, for purposes of the current example, it is assumed that the rendezvous system <NUM> determines that Server A <NUM> is the preferred server from which the content is to be retrieved and, as a result, obtains a corresponding server identifier for Server A <NUM>.

After identifying a server, the rendezvous system <NUM> may return a domain name to the CMS <NUM> corresponding to the identified server. The CMS <NUM> may then return the domain name to the client device <NUM>. 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 device <NUM> and the CDN portion containing the server (e.g. "Denver"), and <domain> is a domain (e.g., "foo. com") associated with the DNS architecture <NUM> for resolving domain names generated by the rendezvous system <NUM>. So, for example, a domain name of "serverA. com" may be returned to the client device <NUM> from the CMS <NUM> as received from the rendezvous system <NUM> if the content is to be retrieved from Server A <NUM> of CDN-A <NUM>.

After receiving the domain name from the CMS <NUM>, the client device <NUM> may provide the domain name to a DNS resolver <NUM> in a DNS request, as described above. In some instances, the DNS resolver <NUM> may forward the DNS request to the DNS architecture <NUM> to obtain a corresponding IP address for server A <NUM>. To resolve the DNS request, the DNS architecture <NUM> may communicate or access a rendezvous lookup table <NUM> including entries that correspond location, server identifier, and a particular IP address of a server of the CDN-A <NUM>. The information included in the rendezvous lookup table <NUM> may be provided to the DNS architecture <NUM> by the rendezvous system <NUM> to correspond server identifiers with IP addresses of servers of the CDN <NUM>. In this manner, the rendezvous system <NUM> may control which servers <NUM>-<NUM> of the CDN <NUM> are associated with the particular server identifiers provided by the rendezvous system <NUM> in response to a query from the CMS <NUM>. The particular IP address for the server identified by the server identifier is then provided to the client device <NUM>. In some instances, the DNS architecture <NUM> may provide a plurality of IP addresses of multiple servers of the CDN <NUM> with some indication of a preference for one server over another. For example, the DNS architecture <NUM> may provide a first IP address for server A <NUM>, a second IP address for server B <NUM>, 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 device <NUM> for accessing servers <NUM>-<NUM> of the CDN <NUM>.

The client device <NUM> may then initiate a session (e.g., a hypertext terminal protocol (http) or similar session) with server A <NUM> to retrieve the requested content. In cases where the content is cached or otherwise stored at server A <NUM>, server A may begin transmitting the content to the client device <NUM>. If, on the other hand, server A <NUM> does 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 CDN <NUM> as described above.

Through the network environment <NUM> of <FIG>, the client device <NUM> may be pushed to request content from a particular server <NUM> of the CDN <NUM>. As content from the CDN <NUM> is cached at the servers <NUM>-<NUM> upon one or more requests for the content, directing client devices <NUM> to particular servers may improve the caching function of the CDN. More particularly, client devices <NUM> requesting 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 CDN <NUM> to cache other content. A repeatable process for directing client devices <NUM> requesting the same content to the same server or servers may therefore improve the efficiency of the CDN <NUM> to provide said content to the client devices <NUM>.

<FIG> is a second example network environment <NUM> including a second rendezvous system <NUM> for processing requests for content available through a CDN <NUM>. Similar to the network environment <NUM> of <FIG>, the network environment <NUM> of <FIG> includes a client device <NUM> in communication with a CMS <NUM>. The CMS <NUM> is configured to present and/or manage requests for content received from the client device <NUM>. In this implementation, the CMS <NUM> again determines which CDN of multiple CDNs for which the requested content may be provided to the client device <NUM>. For example, CMS <NUM> may select CDN-A <NUM> from a plurality of available CDNs to provide the content. In response to the request for content received at the CMS <NUM>, the CMS may return to the client device <NUM> a redirect instruction to access the rendezvous system <NUM> of the environment <NUM>. In other words, rather than the CMS <NUM> accessing the rendezvous system <NUM> to obtain the server identifier of the CDN <NUM> as above, the client device <NUM> may be redirected, based on information provided by the CMS <NUM>, to the rendezvous system <NUM>. 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 system <NUM>, a geographic location identifier of an estimated location of the client device <NUM>, and/or other information for redirecting the client device <NUM>.

In response to receiving the redirect instruction from the CMS <NUM>, the client device <NUM> may transmit a server identification request to the rendezvous system <NUM> to identify the particular server within the CDN <NUM> from 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 device <NUM>. The rendezvous system <NUM> then generates and returns a domain name to the client device <NUM>. As previously discussed, the domain name may include, among other things, identifiers corresponding to a specific server <NUM> of a specific CDN <NUM> from which the requested content may be retrieved and may be generated by the rendezvous system <NUM> based on one or more of location data <NUM> and/or CDN data <NUM>, as previously discussed above. In addition, the rendezvous system <NUM> may execute a hashing function or other similar algorithm to select the server <NUM> of the CDN <NUM> for providing the requested content.

The client device <NUM> may then submit the received domain name to a DNS resolver <NUM> and/or the DNS architecture <NUM> to resolve the domain name to an IP address of the server <NUM> from which the content may be retrieved, as described. The client device <NUM> may then connect to the server <NUM> and request the content.

In still another instance, one or more of the functions of the rendezvous system <NUM>, <NUM> may be performed by the CMS <NUM>. For example, the rendezvous system <NUM> may provide the hashing function executed to determine the particular server <NUM> of the available servers <NUM>-<NUM> of the CDN <NUM>. The CMS <NUM> may then execute the hashing function to obtain the server identifier for the selected server and provide the server identifier accordingly. In addition, the CMS <NUM> may be given access to location database <NUM> and/or CDN database <NUM> to determine the available servers of the CDN <NUM> for providing the content to the client device <NUM>, based on the content identifier and/or the geographic location identifier of the client device <NUM> received at the CMS <NUM>.

<FIG> is a flow chart illustrating a method <NUM> for processing requests for content available through a CDN <NUM>. In one instance, the operations of the method <NUM> may be executed by the rendezvous system <NUM>, <NUM> of the network environment <NUM>, <NUM> described above. In other instances, other systems or devices of the environments discussed above may execute one or more of the operations. For example, CMS <NUM>, DNS architecture <NUM>, and/or the client device <NUM> may 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 operation <NUM>, the rendezvous system <NUM> may obtain CDN architecture data from the CDN database <NUM>. In particular, the rendezvous system <NUM> may determine one or more servers available in a particular location serviced by the CDN-A <NUM>. For example, the rendezvous system <NUM> may determine that servers A-C <NUM>-<NUM> of CDN-A <NUM> may 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-A <NUM> and may include more or fewer content servers <NUM>-<NUM>. For example, a large metro area may include <NUM> servers to provide content to requesting devices within the metro, while a smaller metro area may include fewer than <NUM> 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 operation <NUM>, the rendezvous system <NUM> may generate a server identification and location table from the CDN architecture data associated with a particular location or metro area of the CDN <NUM>. Using the example illustrated in <FIG>, the CDN-A <NUM> may include three servers (namely server A-C <NUM>-<NUM>) for providing content to requesting devices in a particular geographic area. The geographic location and the three servers <NUM>-<NUM> available to provide content may be obtained from the CDN database <NUM> by the rendezvous system <NUM> and a table associating the three servers <NUM>-<NUM> and 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 system <NUM>. In one particular example, the servers <NUM>-<NUM> available 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, servers <NUM>-<NUM> of the CDN <NUM> may be included in the table with server IDs as discussed above, such as "serverA. 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 CDN <NUM> are 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 CDN <NUM> to redirect traffic from the failed server to the redundant server.

In operation <NUM>, the rendezvous system <NUM> may provide, to the DNS architecture <NUM>, access to the generated server ID/location table or to the information included in the table. In one instance, the rendezvous system <NUM> may maintain the rendezvous table in a database <NUM> and notify the DNS architecture <NUM> of the presence of the table in the database <NUM>. In another example, the rendezvous system <NUM> may provide the table to the DNS architecture <NUM>, which may store the table in the rendezvous table database <NUM>. Updates to the table may occur in a similar manner in which the rendezvous system <NUM> may provide the updates to the DNS architecture <NUM> that may update the rendezvous table database <NUM> accordingly. Regardless of the database used, the DNS architecture <NUM> may be provided access to the information contained in the rendezvous table <NUM> such that the DNS architecture <NUM> may respond with an IP address of a server <NUM> of the CDN <NUM> based on a DNS request provided by a requesting device <NUM>. The DNS request may include a server ID as noted above from which the DNS architecture <NUM> may access a corresponding IP address for the target server of the CDN <NUM>.

In operation <NUM>, the rendezvous system <NUM> may receive, from a requesting device such as the CMS <NUM> or client device <NUM>, a request for content that includes an identifier of the requested content and an identifier of a location of the client device <NUM>. As described above, the CMS <NUM> may provide the content request based on information provided to the CMS <NUM> from the client device <NUM>. Alternatively, the client device <NUM> may be redirected to provide the rendezvous system <NUM> with 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 operation <NUM>, the rendezvous system <NUM> may 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 device <NUM>. For example, the rendezvous system <NUM> may utilize the CDN data <NUM> to 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 device <NUM>.

In one specific example, the rendezvous system <NUM> may use a distributed consistent hashing scheme. Consistent hashing is based on mapping each object (here, either servers of the CDN <NUM> or 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 <NUM> to <NUM>^n-<NUM> and, as a result, the corresponding hash key space may include <NUM>^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: <MAT> 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 <NUM> 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 CDN <NUM> for 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 data <NUM> accessible by the rendezvous system <NUM>. In other implementations, other data from which the server may be identified may be stored and accessible by the rendezvous system <NUM> such that the rendezvous system may dynamically identify the particular server from which content may be retrieved. The rendezvous system <NUM> may then calculate a serverID based on the number of servers identified in the CDN data <NUM> for the particular location of the client device <NUM>.

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 server <NUM> always result in the requesting device being directed to the same server <NUM>. 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 CDN <NUM>. This may open up caching space for other content to be cached, improving the efficiency of the caching scheme of the CDN <NUM>.

In operation <NUM>, the rendezvous system <NUM> may transmit the determined server ID to the requesting device from which the content request was received. For example, the rendezvous system <NUM> may transmit the server ID to the CMS <NUM> or the client device <NUM>. The server ID may be, in some instances, included in a domain name, such as "serverA. As described above, this domain name may be used by the client device <NUM> as a portion of a DNS request to the DNS architecture <NUM> to obtain an IP address or other network address for the selected server <NUM> of the CDN <NUM> for providing the content.

In certain implementations of the present disclosure, the client device <NUM> may receive multiple domain names and/or IP addresses in response to a content request. For example, in one implementation, the rendezvous system <NUM> may 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 device <NUM> when resolving a domain name received from the rendezvous system <NUM>. In such cases, the DNS architecture <NUM> may be configured to provide multiple IP addresses in response to receiving a domain name identifying a particular server of a CDN <NUM>.

<FIG> is a block diagram illustrating an example of a computing device or computer system <NUM> which may be used in implementing the embodiments of the network disclosed above. In particular, the computing device of <FIG> is 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 processors <NUM>-<NUM>. Processors <NUM>-<NUM> may include one or more internal levels of cache (not shown) and a bus controller or bus interface unit to direct interaction with the processor bus <NUM>. Processor bus <NUM>, also known as the host bus or the front side bus, may be used to couple the processors <NUM>-<NUM> with the system interface <NUM>. System interface <NUM> may be connected to the processor bus <NUM> to interface other components of the system <NUM> with the processor bus <NUM>. For example, system interface <NUM> may include a memory controller <NUM> for interfacing a main memory <NUM> with the processor bus <NUM>. The main memory <NUM> typically includes one or more memory cards and a control circuit (not shown). System interface <NUM> may also include an input/output (I/O) interface <NUM> to interface one or more I/O bridges or I/O devices with the processor bus <NUM>. One or more I/O controllers and/or I/O devices may be connected with the I/O bus <NUM>, such as I/O controller <NUM> and I/O device <NUM>, as illustrated.

I/O device <NUM> may 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 processors <NUM>-<NUM>. 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 processors <NUM>-<NUM> and for controlling cursor movement on the display device.

System <NUM> may include a dynamic storage device, referred to as main memory <NUM>, or a random access memory (RAM) or other computer-readable devices coupled to the processor bus <NUM> for storing information and instructions to be executed by the processors <NUM>-<NUM>. Main memory <NUM> also may be used for storing temporary variables or other intermediate information during execution of instructions by the processors <NUM>-<NUM>. System <NUM> may include a read only memory (ROM) and/or other static storage device coupled to the processor bus <NUM> for storing static information and instructions for the processors <NUM>-<NUM>. The system set forth in <FIG> is 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 system <NUM> in response to processor <NUM> executing one or more sequences of one or more instructions contained in main memory <NUM>. These instructions may be read into main memory <NUM> from another machine-readable medium, such as a storage device. Execution of the sequences of instructions contained in main memory <NUM> may cause processors <NUM>-<NUM> to 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. 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.

Claim 1:
A method of processing content requests comprising:
generating, by a rendezvous system (<NUM>), based on an architecture of a content distribution network (<NUM>), CDN, in a geographic location, a server identifier look-up table (<NUM>) that corresponds a plurality of server identifiers with a plurality of network addresses, each network address associated with a content server (<NUM>, <NUM>, <NUM>) of a plurality of content servers of the CDN (<NUM>) in the geographic location;
receiving, at the rendezvous system (<NUM>), a request for content from the CDN (<NUM>), the content request including each of a content identifier associated with a content file and a location identifier associated with a geographic location of a client computing device;
obtaining, by the rendezvous system (<NUM>) based on the location identifier and the content identifier, a server identifier corresponding to a content server (<NUM>, <NUM>, <NUM>) of the plurality of content servers of the CDN (<NUM>) in the geographic location associated with the location identifier; and
transmitting, by the rendezvous system (<NUM>) to a requesting device, a domain name comprising the server identifier, wherein a domain name system, DNS, resolver, upon receiving the server identifier from the requesting device, returns, based on the server identifier look-up table (<NUM>), a network address of the content server (<NUM>, <NUM>, <NUM>) to the requesting device for caching the content at the content server (<NUM>, <NUM>, <NUM>);
wherein the content request is received from a content management system (<NUM>), CMS, and transmitting the domain name comprises transmitting the domain name to the CMS (<NUM>), and
the location identifier is inserted into the content request by the CMS (<NUM>), the location identifier associated with a geographic location of a client computing device (<NUM>) to which the content is to be served.