Hacker News new | past | comments | ask | show | jobs | submit login

> But the app seems to be focused on streaming very popular torrents, which means that generally all pieces will be available enough.

This lacks a lot of foresight.

> Also, all Popcorntime clients want the same blocks first, meaning they will both need and seed the first blocks more. So they do not cause an imbalance, as long as there are always some peers that have the full movie.

And this is just plain wrong.




Saying someone is wrong isn't useful if there is no explanation.


From uTorrent's website [1]:

"If everyone streamed every file at the same time, the ecosystem would be negatively affected. That’s why we’ve put in safeguards to protect the ecosystem such as disallowing streaming when there aren’t enough seeders for a file, and preventing users from streaming more than a single file at a time. With these protections, we’ve tested and found no negative effect on the ecosystem. This is a property we’ll continue to monitor and adjust for as streaming becomes more widely used."

[1]: http://www.utorrent.com/help/faq/ut3



> The older peers have already completed the first few files and thus aren't interested in younger peers who currently download the first file exclusively, thus no mutually beneficial relationship can be established between different "generations" of prioritizing peers, effectively splitting the swarm into sparsely connected sets.

I don't understand this. Why does it need to be mutually beneficial? The peers should "pay it forward" by uploading to younger peers, even if the ones they downloaded from are not benefitting.

> On a small swarm this behavior can lead to pieces drop to the 0 availability because some peers concentrate on the first few files while the last peer/seed that has the rare piece in one of the later file quits after doing his fair share, but he only uploaded data for the first few files because the prioritizing peers were interested in those only.

This could be mitigated by using excess bandwidth beyond that needed for streaming to download rare chunks, and ensuring that the streaming application keeps seeding for a while after the video has been watched.


> This could be mitigated by using excess bandwidth beyond that needed for streaming to download rare chunks, and ensuring that the streaming application keeps seeding for a while after the video has been watched.

That wouldn't be streaming then, would it?


Why wouldn't it be? It is still streaming and it will start playing the video soon after you hit the play button instead of downloading the entire video first. The only difference is that it will be caching the download for a certain period of time and possibly downloading rare chunks with extra bandwidth ahead of when the chunks are actually needed. The truth is though, if the torrent is not top heavy with seeders then it is no good anyway so I don't really get why people are so focused on rare chunks.


I'd say it's more of a middle ground between streaming and normal torrent behavior.


The peers with less of the file and further from the seeders will tend to have higher bandwidth as they have more peers they can download from. The vast majority of the network is after only one piece of the file and few peers have it. This collapses the network into a more tree like structure (rather than the desired mesh) which limits the network bandwidth. Whether this is enough to degrade the swarm to the point were it is not useful for streaming or even causes the file to become incomplete is another question, but it does impact bandwidth. I can give an example if this still isn't apparent, but it'd take me a bit to write up.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: