> The intent here is to try a connection that is almost guaranteed to work first (I used a similar rationale in the minimal viable SDP post recently even) and then switch to a peer-to-peer connection in order to minimize the load on the TURN servers. Wow, that is pretty slick.
It's quite interesting. It reminds me of this paper[0] I read some years ago while researching about P2P. It's about how Spotify accomplishes the media streaming... It goes this way IIRC:
1.- Spotify first reads the user's cache looking for media chunks (usually 50% of the played media comes from here since users play the same songs repeatedly)
2.- If the media is not found, then starts streaming directly from server (0-10% of the media comes this way) while peers organise and aggregate (few seconds).
3.- Finally the rest is streamed via P2P (usually 40% of the media).
In both cases, it's certainly a smart approach for a slick UX since the users don't perceive the long setup/loading time required in a direct P2P connection.
1 comment
[ 2.4 ms ] story [ 15.2 ms ] threadIt's quite interesting. It reminds me of this paper[0] I read some years ago while researching about P2P. It's about how Spotify accomplishes the media streaming... It goes this way IIRC:
1.- Spotify first reads the user's cache looking for media chunks (usually 50% of the played media comes from here since users play the same songs repeatedly)
2.- If the media is not found, then starts streaming directly from server (0-10% of the media comes this way) while peers organise and aggregate (few seconds).
3.- Finally the rest is streamed via P2P (usually 40% of the media).
In both cases, it's certainly a smart approach for a slick UX since the users don't perceive the long setup/loading time required in a direct P2P connection.
[0] http://wenku.baidu.com/view/0d85d7264b35eefdc8d33352.html