In my opinion, NAT and the extensive tracking that has led users to distrust sharing their IP addresses are the reasons why it hasn't caught on.
Imagine YouTube using P2P technology, it would save lot of money spent on caching servers.
61–70 of 231 posts
In my opinion, NAT and the extensive tracking that has led users to distrust sharing their IP addresses are the reasons why it hasn't caught on.
Imagine YouTube using P2P technology, it would save lot of money spent on caching servers.
If you want live high quality streaming, a lot of reasons bit torrent works so well goes away.
Latency matters. In bit torrent if the peer goes away, no big deal, just try again in 5 minutes with another peer, you are downloading in random order, who cares if one piecs is delayed 5 minutes. In a live stream your app is broken if it cuts out for 5 minutes.
In bit torrent, everyone can divide the work - clients try to download the part of the file the least number of people have, quickly rare parts of the file spread everywhere. In streaming everyone needs the same piece at the same time.
Bit torrent punishes people who dont contribute by deprioritizing sending stuff to peers that freeride. It can do this on the individual level. In a p2p streaming setup, you probably have some peers getting the feed, and then sending it to other peers. The relationship isnt reciperocal so its harder to punish freeriders as you can't at the local level know if the peer you are sending data to is pushing data to the other nodes it is supposed to or not.
I'm sure some of these have work arounds, but they are hard problems that aren't really satisfactorily solved
There is peertube and webtorrent, but they does not seem to catch the mainstream users. In my opinion, NAT and the extensive tracking that has led users to distrust sharing their IP addresses are the reasons why it hasn't caught on. Imagine YouTube using P2P technology, it would save lot of money spent on caching servers.
> Imagine YouTube using P2P technology, it would save lot of money spent on caching servers.
I think its money well spent.
People have tried to build BitTorrent clients to do this. As far as I know they never took off. The primary problem is you oftentimes don't get people who want to share back or who have firewalls or other connections that don't allow them to share back. So you end up with a few people who end up seeding everything out. The second problem is in order to watch a streaming protocol things need to arrive in order. It is…
Part of the reason bit torrent works really well is that the file is downloaded in random order. It lets everyone cooperate, while still being robust to bad peers, bad network connections, churn etc. If you want live high quality streaming, a lot of reasons bit torrent works so well goes away. Latency matters. In bit torrent if the peer goes away, no big deal, just try again in 5 minutes with another peer, you are do…
1. locally-randomizing segments download order
2. Create a larger buffer
3. Prioritize parts coming from slower connections
People have tried to build BitTorrent clients to do this. As far as I know they never took off. The primary problem is you oftentimes don't get people who want to share back or who have firewalls or other connections that don't allow them to share back. So you end up with a few people who end up seeding everything out. The second problem is in order to watch a streaming protocol things need to arrive in order. It is…
what about having something reasonable for lag, like 30-60 seconds would that make a big difference or you think it would just eventually degrade too? Also do you think there's any way you can prioritize seeders in such a protocol? like some kind of algorithm that the more you share the more you're prioritized in getting the most up to date packets. The main reason I would think it would be useful is 1. since streami…
I think you would probably need something more in the neighbourhood of 10 minutes to really make a difference. If you could make a stable p2p live streaming app with the number of peers all watching the same stream in the hundreds and only 30 seconds latency, i'd consider that pretty amazing.
> Also do you think there's any way you can prioritize seeders in such a protocol? like some kind of algorithm that the more you share the more you're prioritized in getting the most up to date packets.
If we are talking about a livestream (and not "netflix" type streaming) then i don't think seeders are a thing. You can't seed a file that isn't finished being created yet.
If you mean more generally punishing free-riders, i think that is difficult in a live stream as generally data would be coming in from a different set of peers than the peers you are sending data out to, so its difficult (maybe not impossible) to know who is misbehaving.
You might want to look into the tradeoffs Discord decided to go with, https://discord.com/blog/how-discord-handles-two-and-half-mi....
Here's some boilerplate for rolling your own, https://blog.swmansion.com/building-a-globally-distributed-w....
In theory you could gain resilience from a P2P architecture but you're going to have to sacrifice some degree of live-ness, i.e. have rendering clients hold relatively large buffers, to handle jitters, network problems, hostile nodes and so on.