Hacker News Reader

Comment by sergiotapia | Hacker News Reader

This is incorrect. By design, torrent participants both download AND upload at the same time. If you don't believe me, check your network activity using the tool that comes with your OS. You'll see significant upload transfer. :)

View on HN

I think you're missing his point.

The success of bittorrent as a swarming protocol is that each client tries to download the least available snippet of the file it wants. This increases the chances that other clients will be able to find 100% of the pieces of a file as they go through the download process.

With popcorn and other streaming-torrent hybrids, the clients requests are biased towards the snippets of file that the user is about to watch. This makes the beginning of the movie widely available (as all clients start there to begin a stream) but increases the chance that bits of the middle or end of the movie aren't available when a given client needs them.

This may be true, but on my network it takes less than 5 minutes to download a 2GB file and 20 minutes to have 200% upload. I usually stop uploading after that. Now if I were to use Popcorn Movie I'd be uploading for much longer period.

And some people have networks where constantly seeding an entire thing—be it a movie or a Linux distro—is not feasible. When you have 3mbps down/1mbps up DSL, it's going to saturate your upload if you leave it unchecked, and still have a very negative impact even if you throttle.

In most countries, your average Internet consumer can't achieve the speeds you described, though. Also, the download-to-upload rate is significantly higher.

For example, my peak download speed is 5Mbits while the upload speed peaks at 0.6Mbits. That's on one of the more expensive packages, too.

Exactly, people seem to forget the usage patterns.

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

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.

> 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.

http://wiki.vuze.com/w/Sequential_downloading_is_bad

> 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.

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

I think you are missing the point as well. People will not start watching movie at the same time. When one person is almost done another just begins the movie, thus as long as there are few initial seeds and healthy interest in the movie it does not matter which order chunks will be downloaded.

This is a _very_ interesting comment. There _must_ be a switch on the logic of the streaming.

If you want to "stream" the torrent, you will need to start with the first chunks But i think we can do something nice about it. We need to add some transfer stats to the downloading and use it.

You have the file xyz.mp4 with 20 chunks.

First, you leech the first 4 chunks (first 20 minutes of the xyz.mp4 file)

Then you analyze aprox. transfer speed. Let's say you are downloading 2 minutes of movie per second.

If you already downloaded the first 20 minutes, you have at least 15 minutes until you need to start downloading the chunk number 5.

We should use those 15 minutes to download the last chunks (20, 19, 18...)

After 15 minutes you start downloading chunk number 5, 6, 7... and repeat the process.

I think this could work fine, YTS should do something about this.

I agree that we should try to make all chunks of a file available for the other peers, but also all files that participate in the p2p network.

I am not sure which kind of structured p2p system popcorn time sues, but if it was a DHT it should make sure that there is replication of the rarest files works too.

So that people who want to watch weird east European movies also have the opportunity, just as those who want to watch the latest blockbuster.

I hope popcorn time does not immediately delete cached chunks...what a waste.

XBMCtorrent approaches this by seeding the movie until you finish watching it. In my experience, movies start playing within the first minute and are finished downloading within the first hour (well, 10-20 minutes for popular content), meaning a large portion of the movie's running time is devoted to seeding 100% of the file.

https://github.com/steeve/xbmctorrent#doesnt-sequential-down...

Intriguing... is that really so much of a factor? To torrent-stream successfully you have to have eventually loaded all snippets from beginning to end of a file and could potentially be offering them for download at most only a couple of hours later than if you downloaded it first snippet.

That is not necessarily true, it will depend on the number of peers and the chunk replication rate. You can tweak the ratios so that the first part is available more often.

In fact,you are also forgetting about the usage of each peer application. With traditional torrents you download the movie, close the app and watch the movie. Total seeding time is the same as the downloading time.

With popcorn time you are seeding WHILE watching the movie, the total seeding time is much, much longer than in the first case.

Most broadband is asymmetrical (ADSL) so the downstream bandwidth is at least an order of magnitude more than upstream. As you download, your upstream bandwidth is saturated just with the acknowledgement traffic (non-payload ACK) of the download.

You can verify the effect yourself by comparing the network upload statistics from your operating system with the seed statistics of your bittorrent client.

> By design, torrent participants both download AND upload at the same time.

That is, by definition, a leech. [1]

Seed: A downloader that obtains 100% of the data becomes a seed.

And here in this case, a while after someone becomes a seed the file gets deleted permanently.

[1] http://en.wikipedia.org/wiki/Glossary_of_BitTorrent_terms

That's a weird definition. If you divide a large file in chunks of different sizes and you are sharing even 1% of them you are already seeding. And the point of popcorn time is that people are participating the p2p overlay much longer than with other p2p applications, thus seeding longer too.

I understand leechers as those who, over time, mostly download rather than upload.

>people are participating the p2p overlay much longer than with other p2p applications

What makes you say this?

Every client worth looking at allows rates to be adjusted, down to zero, if need be. Case in point http://screenshots.en.sftcdn.net/blog/en/2008/11/utorrent-3....

Reply on news.ycombinator.com