Client-side method for identifying an optimum server

• US 7,299,291 B1
• Filed: 05/17/2001
• Issued: 11/20/2007
• Est. Priority Date: 05/18/2000
• Status: Expired due to Term

• Current Assignee: Akamai Technologies, Inc.
• Original Assignee: Akamai Technologies, Inc.
• Inventors: Shaw, David M.
• Primary Examiner(s): Cardone; Jason
• Assistant Examiner(s): Taylor; Nicholas R
• Application Number:
  US09/859,708
• Time in Patent Office: 2,378 Days
• Field of Search: 709/223, 709/225, 709/231
• US Class Current: 709/231
• CPC Class Codes: H04L 65/61 for supporting one-way streaming services, e.g. Internet radio
• CPC Class Codes: H04L 65/80 Responding to QoS
• CPC Class Codes: H04L 67/1001 for accessing one among a plurality of replicated servers
• CPC Class Codes: H04L 67/1008 based on parameters of servers, e.g. available memory or workload monitoring of computer activity G06F11/30
• CPC Class Codes: H04L 67/101 based on network conditions
• CPC Class Codes: H04L 67/1021 based on client or server locations
• CPC Class Codes: H04L 67/1038 Load balancing arrangements to avoid a single path through a load balancer

Abstract

A client player performs a query to a nameserver against a network map of Internet traffic conditions. The query is made asking for a particular service (e.g., RTSP) via a particular protocol (TCP) in a particular domain. In response, the nameserver returns a set of one or more tokens, with each token defining a machine or, in the preferred embodiment, a group of machines, from which the player should seek to obtain the stream. The player may then optionally perform one or more tests to determine which of a set of servers provides a best quality of service for the stream. That server is then used to retrieve the stream. Periodically, the client player code repeats the query during stream playback to determine whether there is a better source for the stream. If a better source exists, the player performs a switch to the better stream source “on the fly” if appropriate to maintain and/or enhance the quality of service. Preferably, the client player publishes data identifying why it selected a particular server, and such data may be used to augment the network map used for subsequent request routing determinations.

Claims

1. An apparatus, comprising:

a processor;

a media player;

a program code module comprising code executable by the processor to carry out the following method steps;

receiving a list of a set of servers, wherein the set of servers is identified by a content delivery network (CDN) map generating process;

issuing a request to each of the set of servers and receiving a response to the request, and using data associated with the response from each of the set of servers to identify a given server in the set of servers;

as a media stream is being received from a first server and rendered by the media player, determining whether the media stream is acceptable according to a given metric;

if the media stream is not acceptable, and as the media stream continues to be received, taking a given action to initiate delivery of the media stream from the given server, wherein the given action includes the steps of;

(a) creating a buffer;

(b) receiving from the first server and caching in the buffer advanced portions of the media stream;

(c) issuing a request to the given server to initiate delivery of the media stream at a given offset; and

(d) rendering the advanced portions of the media stream;

receiving the media stream from the given server; and

when the given offset is reached, rendering in the media player the media stream received from the given server.

2. The apparatus as described in claim 1, wherein the code is executable by the processor to initiate an instruction to the first server to cease transmission of the media stream before rendering the advanced portions of the media stream.

3. The apparatus as described in claim 1, wherein the code is executable by the processor to match data packets received from the first server and the given server such that the media stream rendered in the media player appears continuous.

4. The apparatus as described in claim 1 wherein the media stream is not acceptable if it is being thinned by the first server.

5. The apparatus as described in claim 1 wherein the media stream is not acceptable if a given indication from the first server is received.

6. The apparatus as described in claim 5 wherein the given indication is that the first server will be unavailable.

7. The apparatus as described in claim 1, wherein the code executable by the processor determines that the given server has a response time that differs from a response time of at least one other server in the set of servers.

8. The apparatus as described in claim 1, wherein the code executable by the processor determines whether the media stream is acceptable periodically as the media stream is being delivered.

9. The apparatus as described in claim 1, wherein the code executable by the processor records given data associated with receipt of the media stream.

10. The apparatus as described in claim 1, wherein the advanced portions of the media stream are created by instructing the first server to increase a delivery rate of the media stream or by instructing the media player to decrease a rendering rate of the media stream.

11. The apparatus as described in claim 1 wherein the request is an RTSP OPTIONS command.

12. The apparatus as described in claim 1 wherein the request is associated with a DNS SRV protocol.

13. The apparatus as described in claim 1 wherein the method carried out by the program code constructs a header that identifies, for each of the set of servers, an IP address for the server, together with a value indicating a time for the response to be returned after issuing the request.

14. The apparatus as described in claim 13 wherein the method carried out by the program code transmits the header to the CDN map generating process to facilitate building of a map of Internet traffic conditions.