The present invention relates to data flow in Peer-to-Peer (P2P) networks. In particular, the invention relates to a transparent transport protocol for use by peers in a P2P network.
Many applications today utilise peer-to-peer (P2P) technology to provide robust, low-cost, scalable delivery of content to end-users. P2P technology is built upon the concept of cooperative peers that share part of their resources with a community in exchange for a service or access to content.
Initially utilised for illegal file sharing, P2P is today utilised for delivery of legal media content on the Internet (e.g. BBC's iPlayer, Joost), telephony (e.g. Skype), free software (e.g. distribution of Linux live CD's over BitTorrent), and service packages (delivery of Microsoft patches over BitTorrent), among others. More and more service providers are realising the benefits of the P2P delivery model, resulting in a general shift towards this type of architecture.
The success of P2P technology is mainly due to its low cost and high scalability. Providers of content have a near-zero cost for delivery of large amounts of data to a large community of users.
In the classical client-server model, the resources on the server side need to be dimensioned to accommodate the total number of simultaneous users of the service. This includes processing power, memory capacity, streaming capacity, read/write speed, bandwidth among others. Conversely, when P2P technology is used, each peer donates part of its resources for the overall good of the network. In order to enable the nodes that would have been clients under the client server model to carry out this function, specific client application software needs to be developed. Different applications generally have different requirements, and different application-specific software generally needs to be installed in a client computer for each application that uses P2P technology.
The development of a peer-to-peer application is not a simple task. Many different companies and open source communities have developed their own proprietary peer-to-peer protocol. These protocols are not interoperable. Efforts to standardise a peer-to-peer protocol have started recently, since electronic vendors (e.g. Set Top Box (STB) vendors) wish to connect their devices to P2P networks, and they cannot implement dozens of different protocols in their equipment which typically possesses very limited resources.
If a service provider wants to utilise P2P technologies, a lot of functions need to be handled by the client applications. This means that “special” software clients need to be implemented to accommodate the needs of a P2P mechanism. Currently, a service provider cannot deliver content using a P2P system without requiring users to install a P2P client. The design and development of new P2P clients is a very time consuming task, and the new applications need to implement a lot of functions already implemented by other applications in the client. This is clearly wasteful and costly.
Since these functions need to be implemented by all P2P applications, most of which are different, many separate non-standardized protocols exist. Furthermore, any new P2P application needs to re-implement all these functions even though other applications on a client computer may already be doing so.
It would therefore be desirable to provide a mechanism to allow applications to utilise P2P technologies in a simpler way.
It is an object of the present invention to overcome or at least mitigate the problems discussed above.
In accordance with one aspect of the present invention there is provided a client node for use in a network. The client node comprises a transmitter for requesting data from the network. A processor is operatively connected to the transmitter, and has installed thereon an operating system and an application. A receiver for receiving data from the network is operatively connected to the processor. The application is arranged to request content data from the network by opening a transport socket to the operating system. The operating system is arranged to establish contact with a master peer server in the network which is the initial source of content, receive a list of sources of the content data from the master peer server through such transport socket signalling, and establish contact with at least one source from the list of sources. The application is arranged to receive the content data from the at least one source without being aware that the content is delivered by at least one source from a list of sources. The list of sources may include nodes in a P2P network or supporting servers.
This allows the client application to be transparent to the use of P2P mechanisms. In other words, the client application need not be aware of the utilisation of a P2P delivery mechanism.
The placement of P2P management functions into the operating system network stack allows them to be used by all the different applications running on top of it. Applications can interact with a P2P transport layer library to get a reference to a P2P transport descriptor (e.g., a socket). This simplifies the development of peer-to-peer client applications.
In particular, this arrangement allows for a mode of operation where the client application has no awareness of the presence of multiple peers. The client application behaves as though it is interacting with a single server, the master peer server. The client application sees one socket that feeds content in a similar manner to that used in the traditional client-server socket. A server can therefore decide to use peer-to-peer delivery with the assistance of a number of distributed peers (or other servers) without placing any major impact on the client application, and even without informing it that this is taking place. This provides servers with a great deal of flexibility: a server can serve clients by itself at periods of low demand, or use a peer-to-peer network at periods of high load.
The operating system may be arranged to control opening and/or closing of sockets towards the at least one source from which the content data is received; and/or control data flow between the at least one source and the application; and/or ordering data chunks received from different peers; and/or ensure content availability to the application; and/or determine what content to retrieve from each source.
In accordance with another aspect of the present invention there is provided a server for use in a network. The server comprises a receiver for receiving a request for content data from a client node in the network and a transmitter for transmitting data into the network. A processor is operatively connected to the receiver and transmitter, and arranged to establish a connection via a three-way handshake with the client node. The processor is further arranged to identify whether there are sources for the content data available in the network and, if sources are available, send a list of said sources to the client node. The list of sources may be sent to the client node using transport socket primitives, and may include nodes that belong to a cluster the server is part of.
In accordance with another aspect of the present invention there is provided a method of delivering content data to an application installed on a client node in a network. The method comprises opening a transport socket from the application to an operating system installed on the client node. Contact is established between the operating system and a master peer server in the network. A list of sources of the content data is obtained at the master peer server, and sent from the master peer server to the operating system. A connection is opened from the client node to at least one source from the list of sources. Content data is received at the application from the at least one source, the use of multiple sources being transparent to the application.
The master peer server may obtain the list of sources of the content data by querying nodes in the network.
The invention also provides an application program adapted to be executed on a client node in a network. The application program is arranged to request content data from the network by opening a transport socket to an operating system installed on the client node. The transport socket causes the operating system to establish contact with a master peer server in the network, receive a list of sources of the content data from the master peer server, and establish contact with at least one source from the list of sources, so that the application can receive the content data from the at least one source.
The invention also provides an operating system program adapted to be executed on a client node in a network. The operating system program is arranged to receive a request from an application installed on the client node to receive content data from the network. It then acts to establish a connection with a master peer server in the network, and receive a list of sources of the content data from the master peer server.
The operating system establishes a connection with at least one source from the list of sources, and enables the application to receive the content data from the at least one source.
The operating system program may further be arranged to control opening and/or closing of sockets towards the at least one source from which the content data is received; and/or control data flow between the at least one source and the application; and/or ordering data chunks received from different peers; and/or ensure content availability at the sources; and/or determine what content to retrieve from each source.
The invention also provides a network stack adapted to operate on a client node in a network. The network stack is arranged to establish a connection with a master peer server in the network and receive a list of sources of the content data from the master peer server. It also establishes a connection with at least one source from the list of sources, and enables an application installed on the client node to receive the content data from the at least one source.
The invention thus moves down certain functions previously implemented by the applications to the transport layer. Instead of having them implemented by every P2P application (in the application itself), these functions are implemented as part of the operating system network stack. It can thus be seen as an enhanced new type of socket, a system library that can be used whenever deemed suitable.
These functions are all handled by the transport layer 202. The P2P application 201 uses the P2P Transport Socket 203 in the same way as standard client applications use TCP sockets. The P2P application 201 does not need to know if the content is really coming from one unique server or from multiple cooperative peers 221, 222, 223, 224, and does not need to be aware of the fact that peer-to-peer will be used as a delivery mechanism. The connections towards multiple peers 221, 222, 223, 224 are hidden from the application 201, that sees one unique socket 203. Full control over the connections with the peers is given to the transport layer 202.
In other words, for any given client computer, the establishment of connections with either a server or with other peers should be handled by the network stack of the operating system of the computer, rather than by an application requesting content. For example, consider a browser for viewing multimedia data. The browser can request data from a network, but will not know whether the data is provided from a single server or a multitude of different sources (peers). The operating system of the computer on which the browser is installed controls the connections to other computers, and sets up the connections with other nodes. There is no need to install specific applications for P2P use: the P2P aspect is handled by the operating system.
In this example, the process of establishment of the Peer-to-peer Transport Socket 203 connection is based on TCP, although it will be appreciated that other protocols may also be used. Initially the client 330 opens a connection to a server (hereinafter referred to as the “Master Peer Server”) 341 which can later signal the usage of multiple cooperative peers 221, 222 back to the client 330. The communication starts as a normal client server interaction which is later amended by the use of cooperative peers. Anything the client P2P application 201 writes to the P2P Transport Socket 203 (in step 1 below) is sent only to the Master Peer Server 341. Referring back to
It will be appreciated that Peer A 221 and Peer B 222 could be either clients or part of a distributed cloud that is under the administrative power of the service provider.
The P2P Transport Socket 203 should be transparent to client applications, and therefore the primitives of usage of the socket should not be changed for the client applications. In one embodiment of this invention the primitives utilised are the same as TCP. Those are open, close, abort, receive, send and status.
The server side (i.e. the Master Peer Server 341) needs to be able to send a transport message to the client transport layer 202 to inform the client 330 about the use of multiple cooperative peers (step 4 in
Moving these functions to the transport layer is compatible with the Open Systems Interconnection Reference Model (OSI) and Internet model. According to these models, the transport layer should provide transparent transfer of data between applications, delivering a (possibly reliable) data transfer services to the applications. Reliability is implemented through flow control (e.g., TCP sliding window), segmentation, and error control. The arrangement described above adds the management of peer connections to the list of services provided by the transport layer. The 1-to-1 transport layer service model has effectively been extended to a many-to-1 where the management of data exchange is performed by the proposed P2P Transport service.
The arrangement described enables applications to be transparent to the use of peer-to-peer technologies. Content and service providers can use the P2P Transport Socket without having to develop complex P2P client applications. Existing applications can be directly ported to the environment containing the proposed transport layer and still work. The system allows servers to redirect the client to multiple peers without having the client to be aware of it. Furthermore, since the P2P functions will be implemented directly on the network stack the performance of the P2P system as a whole will be superior.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/EP2009/057632 | 6/18/2009 | WO | 00 | 12/19/2011 |
Publishing Document | Publishing Date | Country | Kind |
---|---|---|---|
WO2010/145709 | 12/23/2010 | WO | A |
Number | Name | Date | Kind |
---|---|---|---|
5907676 | Fujishiro et al. | May 1999 | A |
6182141 | Blum et al. | Jan 2001 | B1 |
6192414 | Horn | Feb 2001 | B1 |
6330560 | Harrison et al. | Dec 2001 | B1 |
7149816 | Port et al. | Dec 2006 | B1 |
7346909 | Eldar et al. | Mar 2008 | B1 |
7424710 | Nelson et al. | Sep 2008 | B1 |
7551614 | Teisberg et al. | Jun 2009 | B2 |
7660306 | Eiriksson et al. | Feb 2010 | B1 |
7689702 | Tripathi et al. | Mar 2010 | B1 |
7724658 | Eiriksson et al. | May 2010 | B1 |
7826350 | Michailidis et al. | Nov 2010 | B1 |
7831720 | Noureddine et al. | Nov 2010 | B1 |
7843906 | Chidambaram et al. | Nov 2010 | B1 |
8171147 | Kaufman et al. | May 2012 | B1 |
8443057 | Kaufman et al. | May 2013 | B1 |
8583832 | Krzanowski et al. | Nov 2013 | B2 |
8671135 | Joshi et al. | Mar 2014 | B1 |
20030167330 | Cohen et al. | Sep 2003 | A1 |
20040042483 | Elzur et al. | Mar 2004 | A1 |
20040221059 | Bush | Nov 2004 | A1 |
20050165932 | Banerjee et al. | Jul 2005 | A1 |
20060129676 | Modi et al. | Jun 2006 | A1 |
20070150558 | Teodosiu et al. | Jun 2007 | A1 |
20070297334 | Pong | Dec 2007 | A1 |
20080046517 | Frohm et al. | Feb 2008 | A1 |
20080059644 | Bakke et al. | Mar 2008 | A1 |
20080195737 | Jokela et al. | Aug 2008 | A1 |
20090100128 | Czechowski et al. | Apr 2009 | A1 |
20090199250 | Assouline et al. | Aug 2009 | A1 |
20100085975 | Wang et al. | Apr 2010 | A1 |
Number | Date | Country | |
---|---|---|---|
20120102151 A1 | Apr 2012 | US |