4 ms·

The protocol for a torrent is that random parts of a file get seeded to random people requesting a file, and that the clients which act as seeds are able to sto

The protocol for a torrent is that random parts of a file get seeded to random people requesting a file, and that the clients which act as seeds are able to store arbitrary amounts of data to then forward to other clients in the swarm. Do the properties about scaling still hold when it's a bunch of people all requesting real time data which has to be in-order? Do the distributed Rokus, Apple TVs, Fire TVs and other smart TVs all have the headroom in compute and storage to be able to simultaneously decode video and keep old video data in RAM and manage network connections with upload to other TVs in their swarm - and will uploading data to other TVs in the swarm not negatively impact their own download speeds?

alex-mohr 2y ago
Yes, the properties about scaling do hold even with near-real-time streams. [1] The problems with using it as part of a distributed service have more to do with asymmetric connections: using all of the limited upload bandwidth causes downloads to slow. Along with firewalls. But the biggest issue: privacy. If I'm part of the swarm, maybe that means I'm watching it? [1]: Chainsaw: P2P streaming without trees, https://link.springer.com/chapter/10.1007/11558989_12 https://link.springer.com/chapter/10.1007/11558989_12
survirtual 2y ago
Use your imagination for just a moment. The torrent is an example of the system I am describing, not the same system. Torrents cannot work for live streams because the entire content is not hashable yet, so already you have to rethink how it's done. I am talking about adding a p2p layer on top of the existing streaming protocol. The current streaming model would prioritize broadcasting to high-bandwidth users first. There should be millions of those in a world-scale stream. Even a fraction of these millions would be enough to reduce Netflix's streaming costs by an order of magnitude. But maybe Netflix isn't interested in saving billions? With more viewers, the availability of content increases, which reduces load on the centralized servers. This is the property of the system I am talking about, so think backwards from that. With a livestream, you want the youngest block to take priority. You would use the DHT to manage clients and to manage stale blocks for users catching up. The youngest block would be broadcast on the p2p network and anyone who is "live" would be prioritizing access to that block. Torrent clients as they are now handle this case, in reverse; they can prioritize blocks closer the current timestamp to created an uninterrupted stream. The system I am talking about would likely function at any scale, which is an improvement from Netflix's system, which we know will fail -- because it did.

alex-mohr 2y ago

Yes, the properties about scaling do hold even with near-real-time streams. [1] The problems with using it as part of a distributed service have more to do with asymmetric connections: using all of the limited upload bandwidth causes downloads to slow. Along with firewalls. But the biggest issue: privacy. If I'm part of the swarm, maybe that means I'm watching it? [1]: Chainsaw: P2P streaming without trees, https://link.springer.com/chapter/10.1007/11558989_12 https://link.springer.com/chapter/10.1007/11558989_12

survirtual 2y ago

Use your imagination for just a moment. The torrent is an example of the system I am describing, not the same system. Torrents cannot work for live streams because the entire content is not hashable yet, so already you have to rethink how it's done. I am talking about adding a p2p layer on top of the existing streaming protocol. The current streaming model would prioritize broadcasting to high-bandwidth users first. There should be millions of those in a world-scale stream. Even a fraction of these millions would be enough to reduce Netflix's streaming costs by an order of magnitude. But maybe Netflix isn't interested in saving billions? With more viewers, the availability of content increases, which reduces load on the centralized servers. This is the property of the system I am talking about, so think backwards from that. With a livestream, you want the youngest block to take priority. You would use the DHT to manage clients and to manage stale blocks for users catching up. The youngest block would be broadcast on the p2p network and anyone who is "live" would be prioritizing access to that block. Torrent clients as they are now handle this case, in reverse; they can prioritize blocks closer the current timestamp to created an uninterrupted stream. The system I am talking about would likely function at any scale, which is an improvement from Netflix's system, which we know will fail -- because it did.