Patent Grant
8639831
The present invention relates generally to techniques for delivering content to one or more clients over a packet-switched network such as the Internet, and more particularly to a method and apparatus using peer-to-peer networks and content delivery network (CDNs) to deliver content to clients.
The providers of popular, large digital files, such as software, music or video files, must keep pace with the ever increasing bandwidth demands for delivering such files. As the popularity of a file increases, a larger number of users request the file and more bandwidth is required to deliver the file. With conventional Hypertext Transfer Protocol (HTTP) file delivery techniques, for example, the bandwidth requirements increase linearly with the number of requesting users, and quickly becomes prohibitively expensive.
Accordingly, there is a continuing need to improve the delivery of content to users over communications networks such as the Internet.
In accordance with the present invention, a method and apparatus is provided for delivering a content file to a client over a packet-switched network. The method begins by determining a suitable throughput required to deliver the content file to the client. Next, the throughput available in a peer-to-peer network for delivering the content file to the client is determined. The required throughput is compared to the available throughput. If the available throughput is less than the required throughput, the available throughput is supplemented with additional throughput. The content is then delivered to the client over the packet-switched network using the available throughput of the peer-to-peer network and the additional throughput.
In accordance with one aspect of the invention, the additional throughput may be provided by a backup server that is employed as a peer in the peer-to-peer network on an as-needed basis.
In accordance with another aspect of the invention, the additional throughput may be provided by a content delivery network.
In accordance with another aspect of the invention, delivery of the content to the client may further include delivering one portion of the content file over the peer-to-peer network and a remaining portion of the content file over the content delivery network.
In accordance with another aspect of the invention, the peer-to-peer network may operate in accordance with a file transfer protocol selected from the group consisting of BitTorrent, Kazaa, eDonkey, Gnutella, and Direct Connect.
In accordance with another aspect of the invention, the backup server may be configured to function as a seed client.
In accordance with another aspect of the invention, a determination is made of a delivery method to be employed in connection with the content file.
In accordance with another aspect of the invention, the delivery method is selected from the group consisting of a streaming media method or a file downloading method.
In accordance with another aspect of the invention, a method is provided for delivering a content file to a client over a packet switched-network. The method begins by delivering at least one portion of the content file over the packet-switched network using a peer-to-peer file transfer model. The method continues by delivering a remaining portion of the content file over the packet-switched network using a client-server file transfer model.
In accordance with another aspect of the invention, a method is provided for receiving a content file over a packet-switched network. The method begins by receiving at least one portion of the content file over the packet-switched network using a peer-to-peer file transfer model. The method continues by receiving a remaining portion of the content file over the packet-switched network using a client-server file transfer model.
As described in more detail below, the present invention can employ both a client-server or content delivery network model and a peer-to-peer file transfer model to transfer content files from a content originator to multiple clients. The content file may be include, without limitation, data, video, audio, html pages and associated embedded objects, and any combinations thereof. In particular, the invention can dynamically choose which download model is most appropriate at any given time for any particular content file that a client wishes to download. Before describing various features of the invention in greater detail, a description of both a peer-to-peer network and a content delivery network will be presented. For clarity of discussion, the two models with be discussed separately with reference to
The most common method by which files are transferred on the Internet is the client-server model. A central server sends the entire file to each client that requests it—both http and ftp operate in this manner. The clients only communicate with the server and not with each other. The main advantage of the client-server model is its simplicity—a user logs onto a server and initiates the download process. Additionally, files are usually available for long periods of time as the servers tend to be dedicated to the task of serving, and are always on and connected to the Internet. Another important advantage of the client-server model is that the Quality of Service provided to the client, in terms of data throughput and latency, is largely controlled by the server and can be effectively guaranteed. In this context, throughput refers to the amount of actual user data (i.e., payload) transmitted per unit time without the overhead of protocol information such as start and stop bits, TCP/IP overhead, HTTP headers, and the like. Throughput can vary with time and depends on a variety of factors such as bandwidth, latency (i.e., the minimum time needed to send the smallest possible amount of data), payload size, packet size, network load, the number of hops required, and so on.
However, the client-server model has significant problems with files that are large and/or very popular such as newly released content. In particular, a great deal of bandwidth and server resources must be dedicated to distributing each file, since the server must transmit the entire file to each client. As a result, the server is burdened with the entirety of the content delivery costs. Because of these problems content providers sometimes employ so-called content delivery service providers (CDSPs) to efficiently deliver the content on their behalf. The CDSP operates a Content Delivery Network (CDN), which is a network of geographically distributed content delivery nodes that are arranged for efficient delivery of content on behalf of third party content providers. A request from a requesting end user for a given content file is directed to a “best” replica, where “best” usually means that the item is served to the client quickly compared to the time it would take to fetch it from the content provider origin server. A content delivery network comprises a set of content delivery servers (CDSs) dispersed across the Internet, as well as a domain name server (DNS) infrastructure, which is used to route user requests to the nearest CDS. The DNS requests sent from the user browser need to be directed to the DNS of the CDSP. One technique is for the CDSP to “takeover” the DNS functionality of the origin site so as to become the “authoritative DNS” for the origin site. CDNs do not eliminate the problems inherent in the client-server model. Rather, they simply transfer the burden of downloading files from the originating content provider to a third party.
A number of techniques have been proposed for reducing the bandwidth demands of file delivery using a client-server model. For example, in a peer-to-peer content sharing model, sometimes referred to as “cooperative distribution,” one or more users that have previously downloaded a file can share the file with other users. A cooperative distribution model allows a server to deliver large files in a reliable manner that scales with the number of requesting users. Among other benefits, cooperative distribution models exploit the underutilized upstream bandwidth of existing users. Current Examples of peer-to-peer networks include systems such as BitTorrent, Kazaa, eDonkey, Gnutella, Direct Connect and the like.
In the BitTorrent file distribution system, for example, content files are divided into blocks and users attempt to find peers that together contain all of the blocks. When multiple users are downloading the same file at the same time, the various users upload blocks of the file to each other. In other words, a BitTorrent user trades blocks of a file that the user has with other required blocks that other users have until the complete file is obtained. The key philosophy of BitTorrent is that users should upload (transmit outbound) at the same time they are downloading (receiving inbound). In this manner, network bandwidth is utilized as efficiently as possible and the cost of uploading a file is redistributed to the users of the file and the cost of hosting a popular file is more affordable. BitTorrent is designed to work better as the number of people interested in a particular file increases, in contrast to other file transfer protocols where more users tend to bog the system down.
Peer-to-peer content sharing models can reduce the costs associated with delivering content to the client because they leverage the available upstream bandwidth of the clients. In this way the bandwidth costs that would otherwise be associated with a centralized download server are greatly reduced. Unfortunately, the Quality of Service provided to the client cannot be guaranteed because it is not under the complete control of the content deliverer, but rather is highly dependent on the number of clients actively downloading the content and the uplink speeds of those clients.
Thus, the present inventor has recognized that neither the client server model, as represented by a content delivery network, for example, nor peer-to-peer models are completely satisfactory for the purpose of delivering content to clients. The methods, systems and techniques detailed below better utilize both file sharing techniques.
In
Each of the clients 101-104 is configured with a client version of a file sharing program (CPRG) 130. The client program 130 is used to download and open the torrent file 124. The client program 130 displays for the user one or more tracker servers, such as tracker servers 141 and 142, which coordinate the action of all the clients or peers. The tracker server only manages connections and does not have any knowledge of the contents of the files being distributed, and therefore a large number of users can be supported with a relatively limited tracker bandwidth. The tracker server maintains lists of clients currently participating in the file sharing process for the desired content file. The user then selects one of the identified tracker servers to contact in order to procure a copy of the content file. The client program 130 then establishes communication with the selected tracker server. The tracker server sends the client program 130 a list of other peers currently downloading blocks of the content file that the clients 101-104 desire.
As an example, if users of clients 101 and 102 select tracker server 141, their respective client programs 130 contact and communicate with the tracker program 150 of the tracker server 141. The tracker program 150 then sends a network list back to each of the connecting clients 101 and 102. Included in the network list is contact information for at least one “seed” client, such as client 104, which has a full copy of the content file that the clients 101 and 102 wish to procure, as well as contact information for clients such as clients 101 and 102 that have recently contacted the tracker server 141 regarding the content file. The client programs 130 of clients 101 and 102 then use the information in the provided network list to establish peer-to-peer communications with the seed client 104 and with one another in order to download the content file. The client connects to those peers to obtain the various blocks of the content file. Such a group of peers connected to each other to share a torrent is often called a swarm. If the swarm contains only the initial seeder, the client connects directly to it and begins to request blocks. As peers enter the swarm, they begin to trade blocks with one another, instead of downloading directly from the seed.
Initially, the seed client 104 may be the only client in the peer-to-peer network that has any of the blocks available for delivery. When a block is successfully downloaded to one of the clients, however, the client program 130 of that client announces to other clients that it now has a block available for downloading. As more clients join the peer-to-peer network along with the clients 101 and 102, this will further serve to speed up the distribution of the content file to all peer-to-peer network clients as they participate in the swarm download. Eventually, all of the blocks of the content file may be available within the peer-to-peer network from peers other than the seed client 104. At that time, the seed client 104 may disconnect itself from the peer-to-peer network.
Before announcing the availability of an assembled block that has been downloaded, the client program 130 will generally first verify that the assembled block is good. It does this, for example, by calculating a hash value for the assembled block and comparing the calculated hash value against a known hash value provided, for example, in the Torrent file 124. If the two hash values match, then the block is determined to be good. In this case, the other peer-to-peer clients are notified by the client program 130 of the assembled block's availability for downloading. On the other hand, if the two hash values do not match, then the block is determined to be corrupted. In this case, the individual blocks for that assembled block are discarded and requested again from the same or different sources (i.e., other clients on the peer-to-peer network). As clients successfully download all blocks of the content file, they may disconnect from the peer-to-peer network. At the same time, other clients may be joining the peer-to-peer network to download the content file from remaining peers in the peer-to-peer network. In order to be notified of such newly joining clients, as well as to maintain its own contact information in the network list, it is useful for a client already participating in a swarm download to periodically re-connect to the tracker server and obtain an updated network list.
Clients 101-104 are employed by users requesting content. The CDSP provides connectivity between clients 101-104 and the content provider network 120 via the CDN 170 and the packet-switched network 180. Although only one CDN 170 is illustratively shown in
The content provider network 120 comprises a plurality of content (origin) servers 1261, through 126q (collectively content servers 126) and an originating domain name server (DNS) 128. In an instance where there are multiple content servers 126, as illustratively shown in
The content delivery network (CDN) 170 comprises a set of cache servers 1101 through 110p (also referred to as “Content Delivery Servers” (CDSs), collectively CDSs 110) on the edge of the network 170, as well as a domain name server (DNS) infrastructure 108, which is used to route user requests to the nearest CDS 110. In operation, DNS requests sent from the clients 101-104 are directed to the DNS 108 of the CDSP 170. This may be accomplished, for example, by allowing the CDSP 170 to “takeover” the DNS functionality of the originating content provider network 120 so as to become the “authoritative DNS” for the originating site.
Content delivery service providers (CDSP) enable distribution of content from the originating sites (i.e., content servers 126) to the CDS servers 110 on the edge of the network 180, which in turn deliver content to the clients 101-104. The distribution mechanism may be based both on push technologies such as multicasting the data to all the edge servers through terrestrial or satellite links or pull technologies such as those used by proxies. The goal is to decrease the latency of user access to the content files by delivering the files from a CDS edge server closest to the user.
As previously mentioned, peer-to-peer networks and content delivery networks both have their advantages and disadvantages. For instance, CDNs require a great deal of bandwidth and server resources since the server must transmit the entire file to each client. As a result, the server is burdened with the entirety of the delivery costs of the content. CDNs, however, can best control the Quality of Service that is provided to the client. Peer-to-peer networks, on the other hand, reduce the burden placed on a centralized server by leveraging the available upstream bandwidth of the clients, but with less control over the Quality of Service that is delivered to the client.
The present invention uses a combination of a content delivery network model and a peer-to-peer network model to transfer files from a content originator to multiple clients to overcome the aforementioned problems and limitations. A number of questions should be answered to determine the optimal combination of the two network models to be used. In particular, it should first be determined how quickly the file needs to be sent to the client. It then needs to be determined how the data can be sent at the required speed with minimal cost.
In determining how quickly the file needs to be sent to the client a primary consideration is the type of medium that the client wishes to receive. For instance, if the content file is to be delivered in real-time (e.g., as a streaming media file) a higher throughput (e.g., bit rate) will be required than if the file is simply to be downloaded to the client. Once the required throughput is determined, it is compared to the throughput of the peer-to-peer network. If the throughput of the peer-to-peer network is sufficient, then this model is used to deliver the content file. On the other hand, if the throughput of the peer-to-peer network is insufficient, then the peer-to-peer network may still be used to deliver the file by supplementing its throughput by other techniques.
One way to supplement or augment the throughput of a peer-to-peer network is to employ what may be referred to as a backup peer server. The backup peer server, which contains a copy of the content file to be delivered, can be used as an additional peer to increase the throughput of the swarm. The backup peer server will be a seed client if it contains a complete copy of the content file to be delivered. The resources of the backup peer server need only be invoked when necessary to increase the throughput of the peer-to-peer network to deliver a particular content file.
Another way to supplement or augment the throughput of the peer-to-peer network is by using a content delivery network to deliver portions of the content files to the client. For instance, a portion of a content file may be reserved for delivery by the content delivery network. The reserved portion of the file may be some fraction (e.g., half) of the file or a certain number of blocks that would otherwise need to be delivered over the peer-to-peer network.
The state server 160 will typically be continuously monitoring the networks depicted in
The content file to be delivered to clients in accordance with the techniques described above may be any type of file to be downloaded, streamed, or delivered over a communications network by any other means. Such files may include, without limitation, application programs and other executable files, data files, audio, video and multimedia files, operating system components, drivers, updates and the like. For example, in some embodiments the files that are downloaded may be software products associated with consumer electronic devices (e.g., personal computers, personal digital assistants (PDAs), video cameras, digital cameras, MP3 players), which software products are made available by the manufacturer or vendor of the consumer electronic devices.
The files or software products to be delivered to the client in some cases may be delivered in accordance with an associated service. For example, the client may contact a web site that provides a customer of a consumer electronic device with product updates, service updates, warranty information or otherwise manages a suite of services available to the customer. In another example, the files to be delivered may be content files (e.g., video) that a client uploads to a central server to be synchronized with other consumer electronic devices, stored and/or shared with other clients. Such content files may be delivered to other clients or consumer electronic devices in accordance with the techniques described herein. The service may also provide ancillary services to the customer, such as allowing the customer to register multiple consumer electronic devices, perform service authentication for each device and manage each of the devices. The consumer may also use the service to create a profile for managing the devices and synchronize content between and among them using the techniques described herein.
This application is a continuation application of U.S. patent application Ser. No. 11/726,956, filed Mar. 23, 2007, entitled “Method and Apparatus for Transferring Files to Clients Using a Peer-to-Peer File Transfer Model and a Client-Server Transfer Model” which is hereby incorporated by reference in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 6065062 | Periasamy et al. | May 2000 | A |
| 6292834 | Ravi et al. | Sep 2001 | B1 |
| 6600721 | Edholm | Jul 2003 | B2 |
| 7010534 | Kraft | Mar 2006 | B2 |
| 7089290 | Hennessey et al. | Aug 2006 | B2 |
| 7103645 | Leighton et al. | Sep 2006 | B2 |
| 7325073 | Shao et al. | Jan 2008 | B2 |
| 7577750 | Shen et al. | Aug 2009 | B2 |
| 7584285 | Hudson et al. | Sep 2009 | B2 |
| 7660906 | Armour | Feb 2010 | B1 |
| 7945689 | Painter et al. | May 2011 | B2 |
| 7949641 | Eatough | May 2011 | B1 |
| 8316406 | Lin et al. | Nov 2012 | B2 |
| 8332484 | Afergan et al. | Dec 2012 | B2 |
| 20020059619 | Lebar | May 2002 | A1 |
| 20020147815 | Tormasov et al. | Oct 2002 | A1 |
| 20020156910 | Senda | Oct 2002 | A1 |
| 20020194108 | Kitze | Dec 2002 | A1 |
| 20020198930 | Jones et al. | Dec 2002 | A1 |
| 20030014759 | Van Stam | Jan 2003 | A1 |
| 20030145093 | Oren et al. | Jul 2003 | A1 |
| 20030217158 | Datta | Nov 2003 | A1 |
| 20040143672 | Padmanabham et al. | Jul 2004 | A1 |
| 20040148424 | Berkson et al. | Jul 2004 | A1 |
| 20040205162 | Parikh | Oct 2004 | A1 |
| 20040236863 | Shen et al. | Nov 2004 | A1 |
| 20050160133 | Greenlee et al. | Jul 2005 | A1 |
| 20050193114 | Colby et al. | Sep 2005 | A1 |
| 20050198290 | Berkey et al. | Sep 2005 | A1 |
| 20050203851 | King et al. | Sep 2005 | A1 |
| 20050268102 | Downey | Dec 2005 | A1 |
| 20060007947 | Li et al. | Jan 2006 | A1 |
| 20060020684 | Mukherjee et al. | Jan 2006 | A1 |
| 20060029093 | Van Rossum | Feb 2006 | A1 |
| 20060107286 | Connor et al. | May 2006 | A1 |
| 20060140134 | O'Brien et al. | Jun 2006 | A1 |
| 20060143293 | Freedman | Jun 2006 | A1 |
| 20060149828 | Kikinis | Jul 2006 | A1 |
| 20060168088 | Leighton et al. | Jul 2006 | A1 |
| 20060179143 | Walker et al. | Aug 2006 | A1 |
| 20060282522 | Lewin et al. | Dec 2006 | A1 |
| 20070005694 | Popkin et al. | Jan 2007 | A1 |
| 20070028133 | Izutsu et al. | Feb 2007 | A1 |
| 20070038578 | Liu et al. | Feb 2007 | A1 |
| 20070067485 | Stotland et al. | Mar 2007 | A1 |
| 20070223453 | Takase et al. | Sep 2007 | A1 |
| 20070288593 | Wang | Dec 2007 | A1 |
| 20080077635 | Sporny et al. | Mar 2008 | A1 |
| 20080089299 | Lindsley et al. | Apr 2008 | A1 |
| 20080098123 | Huang et al. | Apr 2008 | A1 |
| 20080235331 | Melamed et al. | Sep 2008 | A1 |
| 20080235391 | Painter et al. | Sep 2008 | A1 |
| 20090157850 | Gagliardi et al. | Jun 2009 | A1 |
| Number | Date | Country |
|---|---|---|
| 1372407 | Oct 2002 | CN |
| 1324546 | Jul 2003 | EP |
| 1643716 | May 2006 | EP |
| 1615403 | Nov 2006 | EP |
| Entry |
|---|
| Venkata N. Padmanabhan et al., “The case for cooperative networking,” Microsoft Research, Carnegie Mellon University, Mar. 2002, 2 pages, http://www.research.microsoft.com/%7Epadmanab/papers/iptps02-with-addendurn.pdf. |
| Chris Dana et al., “BASS: BitTorrent Assisted Streaming System for Video-on-Demand,” 2005 IEEE 7th Workshop on Multimedia Signal Processing, Oct. 1, 2005, pp. 1-4. |
| Dongyan Xu et al., “Analysis of a CDN-P2P Hybrid Architecture for Cost-Effective Streaming Media Distribution”, Multimedia Systems, Mar. 17, 2006, vol. 11, No. 4, pp. 383-399, Springer, Berlin, DE. |
| Number | Date | Country | |
|---|---|---|---|
| 20110191420 A1 | Aug 2011 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11726956 | Mar 2007 | US |
| Child | 13084039 | US |
