Particular embodiments generally relate to content delivery systems.
A content delivery network (CDN) is a distributed network of content delivery nodes. The content delivery nodes serve content to one or more clients requesting the content. The content delivery nodes are usually dispersed across many geographical locations. For example, one node may be located in New York and another may be located in San Francisco.
If a large multimedia file is downloaded, choosing a non-optimal location to serve the content may lead to a large penalty of content delivery. For example, a large amount of data will have to be transported across more network links. This may cause delay in serving the content to the user. For example, if a user is in San Francisco and the New York server is selected, additional latency may be experienced than if the server in San Francisco was selected and the content will have to be transported all the way from New York to San Francisco unnecessarily, thereby causing inefficient utilization of Service Provider networks.
Overview
Particular embodiments generally relate to determining a server for delivering content.
In one embodiment, a first request is received for a probe link from a client that has downloaded a page. The request is received from an application. A test may be performed to determine a server that could optimally service a content request from the client. For example, round trip times are calculated for different servers, and the round trip time determined to be the most optimal for the client is selected. After receiving the request, the content router sends a re-direct to the client where the re-direct causes the client to follow the re-direct to the server. The server then sends a re-direct back to the client, which the client follows by sending a second request to the content router. The second request is associated with the client and the round-trip time is calculated for the server. For example, the round trip time is based on a time when the re-direction link was sent and the second request is received. It is then determined if the location for the server should be designated as the content deliverer to the client based on the calculated round-trip time. For example, multiple locations are tested and the location with the lowest round trip time may be selected as the content deliverer.
Particular embodiments use application layer re-direction to determine a server. For example, a hypertext transfer protocol (HTTP) re-direction is used to cause the client to send a re-direct to the server. The server then responds to the re-direction, which then causes the client to send a second request back to the server. Accordingly, an application layer solution is provided that can measure the round-trip time and determine a location that may be optimal to deliver content to the user.
Content router 102 is configured to determine a location 108 that should be the content deliverer for client 104. Content router 102 is a device that intercepts client requests directed at a CDN (Content Delivery Network). It is the job of the content router to ensure that content is fetched from a server in a location that is optimal with respect to the client. For example, a closest location to client 104 may be selected. Although the closest location is described, it will be understood that other factors may be used to determine which server 106 is the optimal server to deliver content to client 104. For example, a server 106 may be closest to client 104, but a network to deliver the content from the location may be experiencing low bandwidth throughput or may have failed. Thus, another server 106 that is not the closest but can deliver the content faster may be determined as the optimal server to deliver the content.
Servers 106 may be any devices that can deliver content. For example, servers 106 can include network devices that can deliver content to client 104. In one example, content may be replicated on servers 106 in different locations 108 in a content delivery network. Depending on location 108, content may be delivered with different latencies to client 104. For example, it is expected that a server 106 that is closest to client 104 may be able to deliver the content the fastest to client 104. Also, other factors may be taken into account, such as the bandwidth available for the network, network failures, etc.
Client 104 includes a computer that may be using a browser to download pages, such as web pages. The web page may be a portal that allows a user to download content. When the user requests content, client 104 may send a request to content router 102.
Location 108 may include multiple servers 106. For example, location 108 may be a server farm or data center that includes multiple routers that can deliver content. The description describes using a server to determine a round trip time. The server may be determined as a representative of location 108 and is used as a basis for determining the round trip time. It will be understood that when the content is delivered, any server in the chosen location may be used.
As will be described below, a server determiner 110 may have already selected a location 108 that should deliver content to client 104 before the user requests the content. This decision may be determined in advance of a user requesting the content.
Server determiner 110 uses an application layer solution that can determine a location 108 to deliver the content to client 104. As will be described in more detail below, an application of client 104 may send a request for a probe link to content router 102. Content router 102 then selects a server 106 for a location 108. A server determiner 110 may then send a re-direction request, such as a hypertext transfer protocol (HTTP) re-direct to client 104. This causes client 104 to re-direct the message to a server 106. Server 106 then sends a re-direct back to the client, which causes the client to send a second request to content router 102. Server determiner 110 can then determine the round-trip time it took for the messages to be sent and received. From that, server determiner 110 may determine if server 106 should be selected to deliver content. For example, the above process may be performed for a number of servers 106 in multiple locations 108. The server 106 that has the lowest round-trip time may be selected as the content deliverer. Other factors may be taken into account, such as bandwidth, to determine a server 106 to deliver content the fastest.
After a user chooses an item to play, depending on the type of uniform resource locator (URL) that points to the content, an HTTP GET or real-time streaming protocol (RTSP) DESCRIBE is generated by a client application of client 104. The request goes to content router 102 and content router 102 re-directs client 104 to the appropriate server 106. To minimize latency experienced by the user, the content routing decision is made in advance, before the play request is received. Thus, instead of waiting for the play request (either the HTTP GET or RTSP DESCRIBE), the content routing decision may be performed when page 200 is first loaded on a browser of client 104. In one case, the content delivery network does not know when a portal page is downloaded, which means content router 102 does not know when the page is loaded. However, the page may include probe links 106 within it. The probe links point to content router 102 such that it is contacted when the page is loaded.
Probe links 206 may be links that cause client 104 to send a request for a probe link to content router 102. Probe links 206 may be rendered as images or can be invisible (e.g, by having the image be a single pixel or by having an image with a single color that is the same color as the page background). For example, when an image is downloaded in page 200, it causes an application to send a request for a probe link to be sent to content router 102. For example, the probe link may be an HTTP request that is sent. Also, the probe links may be invisible and embedded in code for page 200. When the code is downloaded, a probe link request may be sent to content router 102.
While the user is browsing page 200 by looking at the content selections, content router 102 may determine the content routing decision in the background. By the time the user selects an item to play, it is possible that content router 102 has made a content routing decision, such as content router 102 may have selected a server 106 to deliver content to client 104. For example, content router 102 may have paired the user's Internet protocol (IP) address with a location 108. The mapping between client 104 and location 108 may be saved in a database. When the request is received, client 104 can be re-directed to location 108 to request the content. This allows a server 106 at the location to deliver content to client 104 in a low latency environment.
Although page 200 is described, a user may access content in other ways. For example, a user may select a media link that was received by email. In this case, the link (URL) may point directly to the content file. When content router 102 receives this URL from a client 104 that it has never seen before, a sequence of redirections are triggered to find out the optimal server 106. Once the server is determined, the content is served from the optimal location and all subsequent requests from the same client can now be redirected to the same location. Content router 102 pairs up client 104 with a location 108 and records this mapping in its database for future requests. Future requests from client 104 do not need to go through the server determination process because a database lookup is used to determine the optimal location 108. The database entries may be invalidated after a configured time interval, after which content router 102 goes through the same determination again for the same client.
At 304, content router 102 determines a location 108 to test and determines a server 106 as a representative. Content router 102 then sends a re-direction message to client 104 that re-directs the client to the selected server 106. For example, an HTTP re-direct, such as status code 307, is sent to client 104. A location field in the re-direct may contain a special uniform resource identifier (URI) that points to a server 106 that is to be probed. This causes client 104 to initiate an HTTP connection with that server 106. It should be noted that the re-direction is an HTTP request from content router 102 to client 104. This may be different than a ping, which might not always work. This is because a client may be behind a firewall and a naked ping from client 104 to content router 102 may not pass through the firewall. Rather, the ping is sent through a port that may not allow the ping. However, an HTTP re-direction to the client in response to the request probe link will pass through the firewall. The ping program depends on Internet control messaging program (ICMP) echo requests to determine round-trip times. A number of Internet Service Providers filter out ICMP echo requests at their boundaries. Particular embodiments use application layer protocol mechanisms such as HTTP or RTSP redirects, thus the requests can pass through unfiltered.
Also, with regard to firewalls, the requests are initiated by client 104 and the firewalls are required not to block the rest of the transaction. The redirect sequence is triggered by client 104 requesting for a probe link and the client establishes a transfer control protocol (TCP) connection with content router 102 and makes a request. The response (a redirect command) from content router 102 to client 104 is passed through to client 104 on the same TCP connection. Firewalls recognize the redirect command as part of the same TCP transaction and let the redirect pass. The redirections from servers 106 are also recognized and passed.
The re-direct causes client 104 to follow the re-direct and initiate an HTTP connection with server 106 at 306. For example, the re-direct sent to client 104 is re-directed to server 106-1. Server 106-1 detects the special URI, which causes it to send a re-direct back to client 104 at 308. This re-direct is followed back to content router 102. For example, client 104 may send an HTTP message: contentrouter/probe to content router 102. This process may be performed for all probe links that are requested. For example, server 106-2 and server 106-3 may also be probed with the above probing of server 106-1. Content router 102 associates an identifier with client 104 and can then calculate the round trip time using a time based on when a previous message was sent. In one example, a round-trip time for each server 106 is calculated. The time elapsed from the initial re-direct at 304 to when the second request from client 104 is received at 310 may be calculated. This may measure the round-trip time between server 106 and client 104. This round-trip time may include the time it took to send the messages from content router 102 to client 104 and from client 104 to content router 102. However, assuming that this time is the same for all servers 106, then it can be included in the calculation.
When multiple locations 108 have been tested, server determiner 110 may then determine an optimal server 104 (or location) to assign as the content deliverer. For example, a location that server determiner 110 determines to be a location that can deliver the content the fastest to client 104 is determined. Different round trip times for servers 106 may be compared and the most optimal location is determined based on the round trip times. A location 108 with the least round-trip time may be determined as the location that should be selected to deliver content to client 104.
In some cases, the optimal location may be better indicated by bandwidth than latency. The bandwidth may be measured by having the probe links point to a dummy HTML file of a suitable size. Over a high bandwidth path, the file will download faster causing a corresponding location 108 to provide a download faster. However, server 106 cannot respond to a GET request by issuing both a 200 OK and a 307-re-direct. Thus, an alternative mechanism to re-direct client 104 back to content router 102 after the probe file has been transferred may be needed. In one example, the probe link on the portal page would be <iframe src=“http://contentrouter/probe.html”><iframe>. When client 104 requests for probe.html from content router 102, it is re-directed to the HTTP address server-in-location1/dummy.html. This file, located on the server 106, may be:
When the file is requested for, the HTTP response from servers uses standard header fields to prevent caching of content. For example, an HTTP response from server 106 has a Cache-Control field set to no-Cache such that dummy.html is not cached anywhere. Loading the above file causes client 104 to contact the content router to request probe.jpg. At this time, content router 102 can compute the round-trip time, which includes the download time for dummy.html.
The probing process may be performed in series or in parallel. For the series process, client 104 may request the probe links in series. For example, once one round-trip has been completed, a second request for a probe link may be sent. If the requests are sent in parallel, the first response from server 106 may be considered to have the least round-trip time, and thus this server 106 may be selected as the server to deliver content to client 104. There is no need to wait for the rest of the locations to finish the race. Thus, the time required to make a content routing decision is minimized.
In the sequential embodiment, only one probe link may be provided on page 200. Content router 102 may probe servers 106 one-by-one by re-directing the same request for the probe link multiple times. When there are many locations, this may cause the number of re-directions to go over the maximum number supported by the browser of client 104. Accordingly, multiple probe links may be provided on page 200 to allow for multiple sequential re-directions.
Also to avoid the redirection limit, a single probe link may fan out into multiple probes. This may be achieved by crafting the single probe as an in-line frame. For example, the probe link on the portal page may be <iframe src=“http://contentrouter/probe”></iframe>, and the page at the HTTP address contentrouter/probe may look like
Thus, loading the portal page results in three probe links being requested by client 104, that is probe 1, probe 2, and probe 3. This also decouples page 200 from the internals of the content deliver network. For example, page 200 does not need to be modified for having a new location to be probed.
When the in-line frame is requested, content router 102 may respond with a page containing probes that point to individual servers 106. This avoids one round-trip from the client to the content router. In this case, the page at HTTP address contentrouter/probe may be:
Also, probe links may not be used on page 200. In this case, the media request that downloads the page may download probe links, which case the re-direct steps before serving the actual content. The user may experience added latency in this case but only for the first request for the page. RTSP requests may also be ping-ponged using the RTSP re-direct messages.
Client 104 may also go through one or more intermediate proxies before reaching content router 102. If this happens, content router 102 may not be able to determine the IP address of client 104. Content router 102 may believe the request originated at the proxy because the proxy acts like it is client 104. This may not allow content router 102 to reliably identify later requests from client 104 to determine the round-trip time. That is, content router 102 needs to determine when the first request was received from a client and associate it with the second request to determine the round-trip time.
When a proxy is used, content router 102 may service the request for a probe link and generate an identifier for client 104. This identifier may be sent to client 104 in the form of an HTTP cookie. Content router 102 records the content routing decision in its database as a mapping between the identifier and the chosen location 108. The next time client 104 requests content from content router 102, client 104 sends over the cookie, which can be used to perform the database look-up using the identifier. This may provide the location that has been selected for client 104.
Step 404 determines a server 106 in which to measure the round-trip time. For example, a server at a location 108 may be determined.
In step 406, a re-direct request is sent from content router 102 to client 104. The request re-directs client 104 to server 106. Server 106 also sends a re-direction back to client 104 which causes it to send a second request to content router 102. In step 408, content router 102 receives the second request from client 104.
In step 410, content router 102 determines the round-trip time.
This process may be performed for multiple servers. Step 412 determines if more locations 108 should be probed. If so, the process reiterates to step 406 where other re-directs are sent. If more locations 108 do not need to be probed, step 414 determines a location 108 that should be the content deliverer to client 104. This may be the location 108 that is closest to client 104 or may have the most bandwidth.
Particular embodiments provide many advantages. For example, extra latency is not added to a request for content. Rather, the content routing decision is performed before the user requests the content. Also, no layer 3 or layer 4 enhancements are required. Also, no domain name service (DNS) support is needed. Rather, an application layer solution is provided where an application at client 104 initiates the probe link request. By using re-directions, the presence of firewalls is not a problem. This is because content router 102 is responding to a request from client 104.
Although the description has been described with respect to particular embodiments thereof, these particular embodiments are merely illustrative, and not restrictive.
Any suitable programming language can be used to implement the routines of particular embodiments including C, C++, Java, assembly language, etc. Different programming techniques can be employed such as procedural or object oriented. The routines can execute on a single processing device or multiple processors. Although the steps, operations, or computations may be presented in a specific order, this order may be changed in different particular embodiments. In some particular embodiments, multiple steps shown as sequential in this specification can be performed at the same time.
A “computer-readable medium” for purposes of particular embodiments may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, system, or device. The computer readable medium can be, by way of example only but not by limitation, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, system, device, propagation medium, or computer memory. Particular embodiments can be implemented in the form of control logic in software or hardware or a combination of both. The control logic, when executed by one or more processors, may be operable to perform that which is described in particular embodiments.
Particular embodiments may be implemented by using a programmed general purpose digital computer, by using application specific integrated circuits, programmable logic devices, field programmable gate arrays, optical, chemical, biological, quantum or nanoengineered systems, components and mechanisms may be used. In general, the functions of particular embodiments can be achieved by any means as is known in the art. Distributed, networked systems, components, and/or circuits can be used. Communication, or transfer, of data may be wired, wireless, or by any other means.
It will also be appreciated that one or more of the elements depicted in the drawings/figures can also be implemented in a more separated or integrated manner, or even removed or rendered as inoperable in certain cases, as is useful in accordance with a particular application. It is also within the spirit and scope to implement a program or code that can be stored in a machine-readable medium to permit a computer to perform any of the methods described above.
As used in the description herein and throughout the claims that follow, “a”, “an”, and “the” includes plural references unless the context clearly dictates otherwise. Also, as used in the description herein and throughout the claims that follow, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.
Thus, while particular embodiments have been described herein, a latitude of modification, various changes and substitutions are intended in the foregoing disclosures, and it will be appreciated that in some instances some features of particular embodiments will be employed without a corresponding use of other features without departing from the scope and spirit as set forth. Therefore, many modifications may be made to adapt a particular situation or material to the essential scope and spirit.
Number | Name | Date | Kind |
---|---|---|---|
4827411 | Arrowood et al. | May 1989 | A |
4965772 | Daniel et al. | Oct 1990 | A |
5345586 | Hamala et al. | Sep 1994 | A |
5414704 | Spinney | May 1995 | A |
5452447 | Nelson et al. | Sep 1995 | A |
5488412 | Majeti et al. | Jan 1996 | A |
5506987 | Abramson et al. | Apr 1996 | A |
5511208 | Boyles et al. | Apr 1996 | A |
5555244 | Gupta et al. | Sep 1996 | A |
5586121 | Moura et al. | Dec 1996 | A |
5611049 | Pitts | Mar 1997 | A |
5673265 | Gupta et al. | Sep 1997 | A |
RE35774 | Moura et al. | Apr 1998 | E |
5740375 | Dunne et al. | Apr 1998 | A |
5751971 | Dobbins et al. | May 1998 | A |
5774660 | Brendel et al. | Jun 1998 | A |
5787470 | DeSimone et al. | Jul 1998 | A |
5818845 | Moura et al. | Oct 1998 | A |
5828655 | Moura et al. | Oct 1998 | A |
5848241 | Misinai et al. | Dec 1998 | A |
5852717 | Bhide et al. | Dec 1998 | A |
5859852 | Moura et al. | Jan 1999 | A |
5867706 | Martin et al. | Feb 1999 | A |
5872773 | Katzela et al. | Feb 1999 | A |
5884025 | Baehr et al. | Mar 1999 | A |
5892903 | Klaus | Apr 1999 | A |
5928331 | Bushmitch | Jul 1999 | A |
5941988 | Bhagwat et al. | Aug 1999 | A |
5946047 | Levan | Aug 1999 | A |
5946048 | Levan | Aug 1999 | A |
5950205 | Aviani, Jr. | Sep 1999 | A |
5953335 | Erimli et al. | Sep 1999 | A |
5956346 | Levan | Sep 1999 | A |
5959660 | Levan | Sep 1999 | A |
5959968 | Chin et al. | Sep 1999 | A |
5959997 | Moura et al. | Sep 1999 | A |
5974547 | Klimenko | Oct 1999 | A |
5989060 | Coile et al. | Nov 1999 | A |
5996021 | Civanlar et al. | Nov 1999 | A |
6006264 | Colby et al. | Dec 1999 | A |
6006266 | Murphy et al. | Dec 1999 | A |
6016388 | Dillon | Jan 2000 | A |
6029175 | Chow et al. | Feb 2000 | A |
6052718 | Gifford | Apr 2000 | A |
6064677 | Kappler et al. | May 2000 | A |
6092178 | Jindal et al. | Jul 2000 | A |
6131121 | Mattaway et al. | Oct 2000 | A |
6157942 | Chu et al. | Dec 2000 | A |
6167438 | Yates et al. | Dec 2000 | A |
6167446 | Lister et al. | Dec 2000 | A |
6181679 | Ashton et al. | Jan 2001 | B1 |
6182139 | Brendel | Jan 2001 | B1 |
6205149 | Lemaire et al. | Mar 2001 | B1 |
6212190 | Mulligan | Apr 2001 | B1 |
6230196 | Guenthner et al. | May 2001 | B1 |
6240461 | Cieslak et al. | May 2001 | B1 |
6260070 | Shah | Jul 2001 | B1 |
6298380 | Coile et al. | Oct 2001 | B1 |
6345294 | O'Toole et al. | Feb 2002 | B1 |
6389462 | Cohen et al. | May 2002 | B1 |
6446121 | Shah et al. | Sep 2002 | B1 |
6449647 | Colby et al. | Sep 2002 | B1 |
6453351 | Endo | Sep 2002 | B1 |
6463475 | Calhoun | Oct 2002 | B1 |
6477522 | Young | Nov 2002 | B1 |
6505254 | Johnson et al. | Jan 2003 | B1 |
6510469 | Starnes et al. | Jan 2003 | B1 |
6542468 | Hatakeyama | Apr 2003 | B1 |
6578077 | Rakoshitz et al. | Jun 2003 | B1 |
6594260 | Aviani, Jr. et al. | Jul 2003 | B1 |
6601098 | Case et al. | Jul 2003 | B1 |
6606643 | Emens et al. | Aug 2003 | B1 |
6742044 | Aviani et al. | May 2004 | B1 |
6757723 | O'Toole et al. | Jun 2004 | B1 |
6891855 | Bruckman | May 2005 | B2 |
6920498 | Gourlay et al. | Jul 2005 | B1 |
6922417 | Vanlint | Jul 2005 | B2 |
6992983 | Chatterjee | Jan 2006 | B1 |
7072979 | Aviani, Jr. et al. | Jul 2006 | B1 |
7080138 | Baker et al. | Jul 2006 | B1 |
7117273 | O'Toole et al. | Oct 2006 | B1 |
7143184 | Shah et al. | Nov 2006 | B1 |
7149771 | Gifford | Dec 2006 | B1 |
7171491 | O'Toole et al. | Jan 2007 | B1 |
7185077 | O'Toole et al. | Feb 2007 | B1 |
7225237 | Tenereillo | May 2007 | B1 |
7281036 | Lu et al. | Oct 2007 | B1 |
7349348 | Johnson | Mar 2008 | B1 |
7395348 | Cieslak et al. | Jul 2008 | B1 |
7401159 | Aviani et al. | Jul 2008 | B1 |
7444428 | Kuo et al. | Oct 2008 | B1 |
7546369 | Berg | Jun 2009 | B2 |
7624164 | Lu et al. | Nov 2009 | B2 |
7650376 | Blumenau | Jan 2010 | B1 |
7720997 | Gourlay et al. | May 2010 | B1 |
7886023 | Johnson | Feb 2011 | B1 |
7899889 | Lu et al. | Mar 2011 | B2 |
8451745 | Weng et al. | May 2013 | B2 |
20020007404 | Vange et al. | Jan 2002 | A1 |
20020112036 | Bohannon et al. | Aug 2002 | A1 |
20030056002 | Trethewey | Mar 2003 | A1 |
20030088671 | Klinker et al. | May 2003 | A1 |
20030233478 | Chuah et al. | Dec 2003 | A1 |
20040001444 | Sadot et al. | Jan 2004 | A1 |
20050226196 | Suh | Oct 2005 | A1 |
20050281205 | Chandwadkar et al. | Dec 2005 | A1 |
20060036724 | Iizuka et al. | Feb 2006 | A1 |
20060072620 | Chatterjee | Apr 2006 | A1 |
20060218301 | O'Toole | Sep 2006 | A1 |
20070097987 | Rey et al. | May 2007 | A1 |
20080028093 | Pickens et al. | Jan 2008 | A1 |
20080270225 | Beygelzimer et al. | Oct 2008 | A1 |
20090234965 | Viveganandhan et al. | Sep 2009 | A1 |
20110302306 | Hanson et al. | Dec 2011 | A1 |
20120185588 | Error | Jul 2012 | A1 |
Number | Date | Country |
---|---|---|
2430416 | Jun 2002 | CA |
101971597 | Feb 2011 | CN |
1344118 | Sep 2003 | EP |
1446917 | Aug 2004 | EP |
2272239 | Jan 2011 | EP |
WO 9818076 | Apr 1998 | WO |
WO 9831107 | Jul 1998 | WO |
WO 9853411 | Nov 1998 | WO |
WO 0063779 | Oct 2000 | WO |
0244848 | Jun 2002 | WO |
WO 03041342 | May 2003 | WO |
WO 2009114558 | Sep 2009 | WO |
Entry |
---|
Michal Szymaniak, et al. “Scalable Cooperative Latency Estimation”, Proceedings of the Tenth International Conference on Parallel and Distributed Systems (ICPADS '04) 1521-9097/04 IEEE, 10 pages. |
PRC Oct. 15, 2012 SIPO 1st Office Action from Chinese Application No. 200980108421.3; 9 pages. |
USPTO Apr. 17, 2012 RCE Response to Jan. 17, 2012 Final Office Action from U.S. Appl. No. 12/406,857. |
USPTO Nov. 29, 2011 Response to Apr. 19, 2011 Non-Final Office Action from U.S. Appl. No. 12/406,857. |
USPTO Jan. 17, 2012 Final Office Action from U.S. Appl. No. 12/406,857. |
“Round-Trip Time Internet Measurements from CAIDA's Macroscopic Internet Topology Monitor,” The Cooperative Association for Internet Data Analysis, 4 pages [retrieved and printed on Mar. 23, 2011] http://www.caida.org/research/performance/rtt/walrus0202. |
“What is my IP Address Location? Find IP Address Search, IP Locator, IP Lookup,” ipaddresslocation.org; 3 pages [retrieved and printed on Mar. 23, 2011] http://www.ipaddresslocation.org/. |
EPO Communication mailed Mar. 17, 2011 for EP 09720444.0; 4 pages. |
Francis, Paul, et al., “An Architecture for a Global Internet Host Distance Estimation Service,” IEEE INFOCOM, Mar. 1999, 17pages; http://idmaps.eeecs.umich.edu/papers/infocom99.ps.gz. |
Francis, Paul, et al., “IDMaps: A Global Internet Host Distance Estimation Service,” IEEE/ACM Trans. on Networking, Oct. 2001, 14 pages; http://idmaps.eecs.umich.edu/papers/ton01.pdf. |
Gueye, Bamba et al., “Constraint-Based Geolocation of Internet Hosts,” ACM Internet Measurement SIGCOMM Conference 2004, 14 pages; http://rp.lip6.fr/˜gueye/articles/ToN—CBG.pdf. |
Jeffery, Clinton L., et al., “Proxy-Sharing Proxy Servers,” First Annual Conference on Emerging Technologies and Applications in Communication, May 1996, 4 pages citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.38.7942&rep=rep1&type=pdf. |
Kwan, Thomas T., et al., “NCSA's World Wide Web Server: Design and Performance,” IEEE Computer, 28(11), Nov. 1995; 23 pages. |
Malpani, Radhika, et al., “Making World Wide Web Caching Servers Cooperate,” Fourth International World Wide Web Conference, Dec. 1995, 11 pages http://www.w3.org/Conferences/WWW4/Papers/59/. |
Oguchi et al., “A Study of Caching Proxy Mechanisms Realized on Wide Area Distributed Networks,” IEEE/IEE Publications Ondisc, 1996, [Abstract Only] http://ieeexpolore.ieee.org/xpl/freeabs—all.jsp?arnumber=546215&isnumber=11475. |
Padmanabhan, Venkata et al., “An Investigation of Geographic Mapping Techniques for Internet Hosts,” Microsoft Research and UC Berkeley, SIGCOMM, San Diego, CA, Aug. 2001; 13 pages; http://reserach.microsoft.com/˜padmanab/papers/sigcomm2001.pdf. |
Padmanabhan, Venkata et al., “Determining the Geographic Location of Internet Hosts,” Microsoft Research and UC Berkeley, SIGCOMM, San Diego, CA, Aug. 2001; 2 pages http://research.microsoft.com/˜padmanab/papers/sigmetrics2001.pdf. |
PCT International Search Report mailed Jul. 12, 2000 for PCT/US00/09377; 1 page. |
PCT International Search Report mailed Jul. 15, 1998 for PCT/US97/23728; 2 pages. |
Ross, Keith, “Hash Routing for Collections of Shared Web Caches,” Sep. 1997; IEEE Network, 21 pages http://citeseerx.ist.psu.edu/viewdoc/similar?doi32 10.1.1.13.821&type=ab. |
USPTO Apr. 19, 2011 Non-Final Office Action from U.S. Appl. No. 12/406,857; 19 pages. |
Wong, Bernard et al., “Geolocalization on the Internet through Constraint Satisfaction,” Worlds '06 Technical Sessions, 3rd Usenix Workshop on Real, Large Distributed Systems, Nov. 5, 2006; 6 pages; http://www.usenix.org/events/worlds06/tech/prelim—papers/wong/wong/html. |
Amini, L. et al., “Client Clustering for Traffic and Location Estimation,” Distributed Computing Systems 2004 Proceedings, 24th Annual Conference on Distributed Computing Systems (ICDCS '04), pp. 730-737 [Abstract Only] http://ieeexplore.ieee.org/ie15/9016/28619/01281641.pdf?arnumber=1281641&htry=2. |
Jul. 18, 2011 Response to EPO Communication dated Mar. 17, 2011 from European Patent Application No. P09720444.0; 11 pages. |
Barzilai et al., “Design and Implementation of an RSVP-Based Quality of Service Architecture for an Integrated Services Internet,” IEEE Journal on Selected Areas of Communications, Apr. 1998, 21 pages; http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.5755. |
Fei, Zongming et al., “A Novel Server Selection Technique for Improving the Response Time of a Replicated Service,” In Proc. of INFOCOM '98, Apr. 1998, 22 pages. |
Guyton, James et al., “Locating Nearby Copies of Replicated Internet Servers,” In Proc. Of SIGCOMM '95, Aug. 1995, 19 pages. |
Information Sciences Institute, “Transmission Control Protocol—DARPA Internet Program—Protocol Specification,” RFC 793, Internet Engineering Task Force, Sep. 1981; 89 pages; http://www.ietf.org/rfc/rfc0793.txt. |
Martin, Arlitt et al., “Evaluating Content Management Techniques for Web Proxy Caches,” Apr. 30, 1999, 10 pages; http://citeseerx.ist.psu.edu/viewdoc/similar?doi=10.1.1.17.4901&type=ab. |
Meyer et al., “Generic Routing Encapsulation (GRE),” RFC 2784; Internet Engineering Task Force, Mar. 2000, 10 pages; http://tools.ietf.org/html/rfc2784. |
Mockapetris, P., “Domain Names—Concepts and Facilities,” RFC 1034, Internet Engineering Task Force, Nov. 1987, 55 pages; http://www.rfc.editor.org/rfc/pdfrfc/rfc1034.txt.pdf. |
Ousterhout, John K., “A Trace-Driven Analysis of the UNIX 4.2 BSD File System,” Jan. 2, 1993, Computer Science Division, Electrical Engineering and Computer Science, University of California, Berkeley, CA, pp. 1-10. |
Ousterhout, John K., “Beating the I/O Bottleneck: A Case for Log-Structured File Systems,” Jan. 30, 1992, Computer Science Division, Electrical Engineering and Computer Sciences, University of California, Berkeley, CA, pp. 1-17; Abstact Only. |
Perkins, Charles E., “Service Location Protocol for Mobile Users,” IEEE, Indoor and Mobile Radio Communications, Sep. 8-11, 1998, pp. 141-146. |
Valloppillil, Vinod, “Cache Array Routing Protocoi v1.0,” Jun. 30, 1997, Internet Draft, http://ds1.internic/net/internet-drafts/draft-vinod-carp-v1-00.txt, pp. 1-6. |
Veizades, J. et al., “The Service Location Protocol,” RFC 2165, Jun. 1997, pp. 1-72; http://tools.ietf.org/html/rfc2165. |
Welch, Brent, “A Comparison of the Vnode and Sprite File System Architectures,” Proceedings of the USENIX File System Workshop, May 1992, 18 pages; http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.46.1535. |
Wessels et al., “ICP and the Squid Web Cache,” IEEE Journal on Selcted Areas of Communications, Apr. 1998, pp. 345-357; http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.108.9934. |
Yang et al., “An Effective Mechanism for Supporting Content-Based Routing in Scalable Server Clusters,” IEEE Parallel Processing. Sep. 21, 1999, pp. 240-245; Abstract Only. |
Baentsch, Michael, et a., “Introducing Application-Level Replication and Naming into Today's Web,” Fifth International World Wide Web Conference, May 1996; 11 pages http://www.geckil.com/˜harvest/www5/papers/P3/overview.html. |
Baker, S.M. et al., “Distributed Cooperative Web Servers,” Computer Networks, Elsevier Science Publishers, May 17, 1999, 18 pages, http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.42.7990. |
EPO Search Report mailed Jul. 29, 2005 for Application No. 01986029.5 (published as EP 1344118); 5 pages. |
Katz, E.D., et al., “A Scalable HTTP Server: The Ncsa Prototype,” Computer Networks and ISDN Systems, vol. 27, pp. 155-164, 11 pgs., 1994 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.5762. |
PCT International Search Report mailed Nov. 6, 2009 for PCT/US2009/036704 (published as WO 2009/114558); 4 pages. |
PCT International Search Report mailed Dec. 23, 2002 for PCT/US02/35158 (published as WO 2003/041342); 1 page. |
PCT International Search Report mailed Jun. 13, 2002 for PCT/US01/44500 (published as WO 02/44848); 4 pages. |
Notification of Transmittal (1 page) of International Preliminary Report on Patentability (1 page) and Written Opinion of the International Searching Authority (7 pages) mailed Sep. 14, 2010 for PCT/US2009/036704 (published as WO 2009/114558). |
Postel J., “Telnet Protocol Specification,” RFC 0764, Jun. 1980, 16 pages; http://tools.ietf.org/pdt/rtc764.pdf. |
Number | Date | Country | |
---|---|---|---|
20090234968 A1 | Sep 2009 | US |