This paper from folks at Spotify primarily focuses on how they use P2P techniques in their platform.
The service is not web-based, but instead uses a proprietary client and protocol. At the heart of the system is this custom music streaming protocol that is optimized for accessing a large library of tracks (and not so much for live broadcasts). The clients are available for several platforms including smart phones. The most notable feature of the Spotify client is its low playback latency. The median latency to begin playback of a track is 265 ms.
The audio streams are encoded using Ogg Vorbis format. It uses TCP as the transport protocol instead of UDP. Between a pair of hosts a single TCP connection is used, and the application protocol multiplexes messages over the connection. While a client is running, it keeps a TCP connection to a Spotify server. Application layer messages are buffered, and sorted by priority before being sent to the operating system’s TCP buffers.
Journey of a song
The journey of a song begins when the client makes a request to Spotify’s servers asking for a new track to be played. In this initial request about 15 seconds worth of music is transferred using the already open TCP connection.
While this is on the client simultaneously issues a search in the P2P network for peers who can serve this track. The client interested in a track also sends a priority attribute in the query to its neighbors. This attribute signifies the urgency of the request and can take on three different values (currently streaming track,prefetching next track, and ofﬂine synchronization).
A serving client/peer sorts these requests by priority and few other parameters and offers the service to top 4 peers.
On receiving the content the client caches it for two reasons 1) it is quite likely that users usually listen to the same song multiple times 2) the cached content can then be used by the client in transmitting the data to other peers in the overlay network. All cached contents are encrypted and are evicted based on an LRU eviction policy.
The same track can be simultaneously downloaded from the server and several different peers. If a peer is too slow in satisfying a request, the request is resent to another peer or, if getting the data has become too urgent, to the server.
Locating tracks on other peers
Instead of a DHT, which is commonly used in most P2P systems, Spotify uses two different mechanisms to locate a track (primarily for performance reasons) -
a) A tracker which is deployed on the back end servers and b) by querying the immediate neighbors in the overlay
The tracker maintains a mapping from tracks to the peers who have the entire song cached with them. It keeps a list of 20 such peers for each song. It also knows which peers are currently available. A client usually asks the tracker for peers who have a specific song with them currently and the tracker responds by providing details of about 10 such online peers.
The queries sent by a client to its immediate neighbors are forward by them in turn to their immediate neighbors. The neighbors send a response back to the client if they have a song cached with them.
There are 2 different ways a track gets played back :
1) The random access case where a fresh track is requested for the first time by a user. This constitutes about 39% of the playbacks in Spotify.
2) The predictable track selection case in which a track gets played either because the previous track ended or the user pressed the forward button. This constitutes about 61% of the playbacks in Spotify.
Spotify is a music streaming service offering lowlatency access to a library of over 8 million music tracks.
Streaming is performed by a combination of client-server access and a peer-to-peer protocol. In this paper, we give an overview of the protocol and peer-to-peer architecture used and provide measurements of service performance and user behavior. The service currently has a user base of over 7 million and has been available in six European countries since October 2008. Data collected indicates that the combination of the client-server and peer-to-peer paradigms can be applied to music streaming with good results. In particular, 8.8% of music data played comes from Spotify’s servers while the median playback latency is only 265 ms (including cached tracks). We also discuss the user access patterns observed and how the peer-to-peer network affects the access patterns as they reach the server.
Previewing from http://www.csc.kth.se/~gkreitz/spotify-p2p10/spotify-p2p10.pdf