4 ms·

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 pee

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

Protostome 2y ago
If I remember correctly, PopcornTime was able to stream via BT. Your claims are mostly correct, but I think some compromises can be made to make BT clients streaming proof. For example: 1. locally-randomizing segments download order 2. Create a larger buffer 3. Prioritize parts coming from slower connections
- eklavya 2y ago
  The main difference is liveness of the stream. Live streams are much much more difficult and much less forgiving.
- lordnacho 2y ago
  This is still just streaming a static file though. Adjusting which segment to get will work, buffering will work, and people don't mind their movie starting a few seconds after they press play. If I'm streaming live, I need the frame immediately, and it doesn't help much to get later frames after the frame I'm missing.
  - jack_pp 2y ago
    what if everyone agrees on a 10s delay?
    - bawolff 2y ago
      The issue is everyone is watching the same part of the file at the same time. Offsetting by 10 seconds does not change that.
      - Timwi 2y ago
        The time offset impedes the ability of viewers to interact with the streamer via chat, which for many people (incl. myself) is the whole reason to watch live instead of a recording.
    - lordnacho 2y ago
      For pseudo-live streams such as sports events, that would be totally fine. People can have slightly out of sync streams, delayed by various amounts. But you can't live stream a conversation with someone if you have a 10s delay.
      - duskwuff 2y ago
        Latency is actually a pretty big deal for live sports events. No one wants to hear the cheering start at the neighbor's house ten seconds before you get to see the team score a goal.
        lordnacho 2y ago
        And yet, that is exactly what we have!
    - delusional 2y ago
      Define "live".
  - Protostome 2y ago
- earnesti 2y ago
  I remember testing popcorn time and other bittorrent streaming tools back in the days. They worked "OK". Yes, you don't get the netflix experience. But on popular titles you get "good enough" streaming experience. You have to wait like 30 secs to get started.
  - fermentation 2y ago
    Part of this was the fact you needed a pretty decent connection speed and that the files themselves were extremely compressed
karel-3d 2y ago
I am not convinced about the random order stuff. If most people will stream from the start then the start will be more seeded? So it's all good. And the order is requested by the client, and there are clients that go in the sequential order, like Deluge
- mihaic 2y ago
  The benefit of a random order is that it forces you to actually keep all the packets, which makes upload more likely. Streaming lets you get away with not storing the whole file, which makes bad actors more likely. And, sure, some BT clients can stream the data, but what the default is makes a huge difference.
  - hinkley 2y ago
    People will shut off the moment they get the full file. The randomness means that the last packet is as likely to exist as the first. Would you want to watch the beginning of something that didn’t have an ending? How frustrating would that be?
    - scott_w 2y ago
      > People will shut off the moment they get the full file. Perhaps but the time spent downloading it is also time spent uploading some of the file, so there's still some benefit. By having it in random order, you more evenly distribute the people with access to different parts of the file. With streaming, if everyone downloads the same blocks at the same time, "bad actors" can dump all data they already watched to save disk space, harming potential peers that are watching slightly behind.
      - hinkley 2y ago
        Proof of work has problems with this because you (Mallory) can be paid to be the tertiary durable store for a file and secretly fetch the file from Alice or Bob when asked to prove you have the files. And even if you do something like use a different cypher for each copy the fact that the data is often meant to be public means one could work out the cypher given Alice and Bob and then dump your copy once you have done so. Unless you use public key cryptography, which is so expensive that nobody actually uses it for arbitrarily large inputs.
delusional 2y ago
I don't think people are appreciating the nuance of what you're saying. Most of what you are saying isn't accurate for netflix style streaming, which would actually be more aptly called "video on demand", but is very applicable to "live streaming" in the sense of live sporting events or news broadcasts. Video-on-demand is perfectly implementable on top of BitTorrent. As you say, there are some latency pitfalls you'll have to avoid, but that's nothing you can't hack yourself out of. Livestreaming is a different beast. As you say, the problem with livestreaming is that everyone needs the same content at the same time. If I spend 200ms downloading the next 500ms worth of content, then there's nobody to share it with, they all spent the 200ms doing the same. BitTorrent relies on the time shift that is allowed between me downloading the content and you requesting it. If you request it before I've got it, well I can't fulfil that request, only the guy I intend to get it from can. If you wanted to implement something like that, you would probably pick a tree of seeders where the protocol would pick a subset of trusted nodes that it would upload the content to before then allowing them to seed it, and the have them doing the same recursively. That would obviously introduce a bunch of complexity and latency, and would very much not be BitTorrent anymore.
- ralferoo 2y ago
  I don't think he's saying it needs to be BitTorrent, just applying some principles from it. For example, say you have a cluster of people on the call in the US and another cluster in the UK. Ping times are 100ms or more across the ocean, there will be some random packets lost, but ping times within the UK are around 15ms max. By working co-operatively and sharing among themselves the clients in one cluster can fill in missing packets from a different cluster far quicker than the requesting them from the originating host. In general, the ability to request missing packets from a more local source should be able to improve overall video call quality. It still might be "too late", because for minimal latency, you might choose to use packets as soon as they arrive and maybe even treat out-of-order packets as missing, and just display a blockier video instead, but if the clients can tolerate a little more latency (maybe a tunable setting, like 50ms more than the best case) then it should in theory work better than current systems. I've been mulling over some of these ideas myself in the past, but it's never been high enough on my TODO list to try anything out.
arghwhat 2y ago
This comments on why bittorrent as is isn't used for live streaming, not why P2P shouldn't be used for live streaming > 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. First of all, BitTorrent clients do not download in random order or wait 5 minutes. They usually download the rarest block first, but can do whatever they want, whenever they want. Second, standard HLS sets a nominal segment size of 6 seconds (some implementations will go as high as 10 seconds), and a client will usually cache multiple segments before playing (e.g., 3). This mean that you have 18 seconds before a segment becomes critical. This is not a difficult thing for a P2P network to handle. You'd adapt things to introduce timing information and manage number of hops, but each client can maintain a connection to a number of other clients and have sufficient capacity to fill a segment if a connection fails. Various strategies could be used to distribute load while avoiding latency penalties. Low-latency HLS uses much smaller segments and would be more demanding, but isn't impossible to manage. > BitTorrent punishes people who dont contribute Private communities punish this behavior, BitTorrent clients do not. Most new downloads will appear as freeriders for a long time, and only over long periods far exceeding the download time will enough compatible seeding opportunities arise for them to contribute in any substantial way. The network does not need everyone to seed, it only needs enough people to seed.
- PaulHoule 2y ago
  I have a relatively slow ADSL connection, it's not unusual for me to be able to download 100% of the file at say 95% the theoretical rate without uploading anything. If the network has enough upload capacity to do this, does it really need my upload? (Note my client is still there if somebody needs a rare block) I remember some Bittorrent networks circa 2005 or so which tried to monitor you and punish you for not contributing and this was a disaster for me since my upload is necessarily a small fraction of my download. What I found is that kind of network seemed to perform poorly even when I had a good bidirectional connection. As I saw it, people who have the ability to upload more than they download are a resource that that kind of network can't exploit if everybody is forced to upload as much as they download.
calvinmorrison 2y ago
> Part of the reason bit torrent works really well is that the file is downloaded in random order. That's basically true for one client (transmission) - who specifically refuses to allow linear ordering. Most clients implement this. To enable it, its about a 3 sloc change. I hate clients that dont work for the user.
- wing-_-nuts 2y ago
  >That's basically true for one client (transmission) - who specifically refuses to allow linear ordering. Most clients implement this. Transmission does allow you to set a particular file (let's say the first file in a series) as 'high priority' though so it's not like they don't allow any change to the behavior
  - calvinmorrison 2y ago
    good for them. they specifically refuse to implement this feature even though its a tiny change for the 'good of the ecosystem' or something stupid.
HumblyTossed 2y ago
Just for shits and giggles, I wonder if a protocol similar to HLS, where each peer is assigned a segment to transcode / cache, would work for best cases. If a peer drops, that segment is assigned to another peer. Or if there are, say, 5 peers, double up on the next segment to increase odds it will be done. Just a mental curiosity is all.

Protostome 2y ago

If I remember correctly, PopcornTime was able to stream via BT. Your claims are mostly correct, but I think some compromises can be made to make BT clients streaming proof. For example: 1. locally-randomizing segments download order 2. Create a larger buffer 3. Prioritize parts coming from slower connections

eklavya 2y ago
The main difference is liveness of the stream. Live streams are much much more difficult and much less forgiving.
lordnacho 2y ago
This is still just streaming a static file though. Adjusting which segment to get will work, buffering will work, and people don't mind their movie starting a few seconds after they press play. If I'm streaming live, I need the frame immediately, and it doesn't help much to get later frames after the frame I'm missing.
- jack_pp 2y ago
  what if everyone agrees on a 10s delay?
  - bawolff 2y ago
    The issue is everyone is watching the same part of the file at the same time. Offsetting by 10 seconds does not change that.
    - Timwi 2y ago
      The time offset impedes the ability of viewers to interact with the streamer via chat, which for many people (incl. myself) is the whole reason to watch live instead of a recording.
  - lordnacho 2y ago
    For pseudo-live streams such as sports events, that would be totally fine. People can have slightly out of sync streams, delayed by various amounts. But you can't live stream a conversation with someone if you have a 10s delay.
    - duskwuff 2y ago
      Latency is actually a pretty big deal for live sports events. No one wants to hear the cheering start at the neighbor's house ten seconds before you get to see the team score a goal.
      - lordnacho 2y ago
        And yet, that is exactly what we have!
  - delusional 2y ago
    Define "live".
- Protostome 2y ago
earnesti 2y ago
I remember testing popcorn time and other bittorrent streaming tools back in the days. They worked "OK". Yes, you don't get the netflix experience. But on popular titles you get "good enough" streaming experience. You have to wait like 30 secs to get started.
- fermentation 2y ago
  Part of this was the fact you needed a pretty decent connection speed and that the files themselves were extremely compressed

karel-3d 2y ago

I am not convinced about the random order stuff. If most people will stream from the start then the start will be more seeded? So it's all good. And the order is requested by the client, and there are clients that go in the sequential order, like Deluge

mihaic 2y ago
The benefit of a random order is that it forces you to actually keep all the packets, which makes upload more likely. Streaming lets you get away with not storing the whole file, which makes bad actors more likely. And, sure, some BT clients can stream the data, but what the default is makes a huge difference.
- hinkley 2y ago
  People will shut off the moment they get the full file. The randomness means that the last packet is as likely to exist as the first. Would you want to watch the beginning of something that didn’t have an ending? How frustrating would that be?
  - scott_w 2y ago
    > People will shut off the moment they get the full file. Perhaps but the time spent downloading it is also time spent uploading some of the file, so there's still some benefit. By having it in random order, you more evenly distribute the people with access to different parts of the file. With streaming, if everyone downloads the same blocks at the same time, "bad actors" can dump all data they already watched to save disk space, harming potential peers that are watching slightly behind.
    - hinkley 2y ago
      Proof of work has problems with this because you (Mallory) can be paid to be the tertiary durable store for a file and secretly fetch the file from Alice or Bob when asked to prove you have the files. And even if you do something like use a different cypher for each copy the fact that the data is often meant to be public means one could work out the cypher given Alice and Bob and then dump your copy once you have done so. Unless you use public key cryptography, which is so expensive that nobody actually uses it for arbitrarily large inputs.

delusional 2y ago

I don't think people are appreciating the nuance of what you're saying. Most of what you are saying isn't accurate for netflix style streaming, which would actually be more aptly called "video on demand", but is very applicable to "live streaming" in the sense of live sporting events or news broadcasts. Video-on-demand is perfectly implementable on top of BitTorrent. As you say, there are some latency pitfalls you'll have to avoid, but that's nothing you can't hack yourself out of. Livestreaming is a different beast. As you say, the problem with livestreaming is that everyone needs the same content at the same time. If I spend 200ms downloading the next 500ms worth of content, then there's nobody to share it with, they all spent the 200ms doing the same. BitTorrent relies on the time shift that is allowed between me downloading the content and you requesting it. If you request it before I've got it, well I can't fulfil that request, only the guy I intend to get it from can. If you wanted to implement something like that, you would probably pick a tree of seeders where the protocol would pick a subset of trusted nodes that it would upload the content to before then allowing them to seed it, and the have them doing the same recursively. That would obviously introduce a bunch of complexity and latency, and would very much not be BitTorrent anymore.

ralferoo 2y ago
I don't think he's saying it needs to be BitTorrent, just applying some principles from it. For example, say you have a cluster of people on the call in the US and another cluster in the UK. Ping times are 100ms or more across the ocean, there will be some random packets lost, but ping times within the UK are around 15ms max. By working co-operatively and sharing among themselves the clients in one cluster can fill in missing packets from a different cluster far quicker than the requesting them from the originating host. In general, the ability to request missing packets from a more local source should be able to improve overall video call quality. It still might be "too late", because for minimal latency, you might choose to use packets as soon as they arrive and maybe even treat out-of-order packets as missing, and just display a blockier video instead, but if the clients can tolerate a little more latency (maybe a tunable setting, like 50ms more than the best case) then it should in theory work better than current systems. I've been mulling over some of these ideas myself in the past, but it's never been high enough on my TODO list to try anything out.

arghwhat 2y ago

This comments on why bittorrent as is isn't used for live streaming, not why P2P shouldn't be used for live streaming > 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. First of all, BitTorrent clients do not download in random order or wait 5 minutes. They usually download the rarest block first, but can do whatever they want, whenever they want. Second, standard HLS sets a nominal segment size of 6 seconds (some implementations will go as high as 10 seconds), and a client will usually cache multiple segments before playing (e.g., 3). This mean that you have 18 seconds before a segment becomes critical. This is not a difficult thing for a P2P network to handle. You'd adapt things to introduce timing information and manage number of hops, but each client can maintain a connection to a number of other clients and have sufficient capacity to fill a segment if a connection fails. Various strategies could be used to distribute load while avoiding latency penalties. Low-latency HLS uses much smaller segments and would be more demanding, but isn't impossible to manage. > BitTorrent punishes people who dont contribute Private communities punish this behavior, BitTorrent clients do not. Most new downloads will appear as freeriders for a long time, and only over long periods far exceeding the download time will enough compatible seeding opportunities arise for them to contribute in any substantial way. The network does not need everyone to seed, it only needs enough people to seed.

PaulHoule 2y ago
I have a relatively slow ADSL connection, it's not unusual for me to be able to download 100% of the file at say 95% the theoretical rate without uploading anything. If the network has enough upload capacity to do this, does it really need my upload? (Note my client is still there if somebody needs a rare block) I remember some Bittorrent networks circa 2005 or so which tried to monitor you and punish you for not contributing and this was a disaster for me since my upload is necessarily a small fraction of my download. What I found is that kind of network seemed to perform poorly even when I had a good bidirectional connection. As I saw it, people who have the ability to upload more than they download are a resource that that kind of network can't exploit if everybody is forced to upload as much as they download.

calvinmorrison 2y ago

> Part of the reason bit torrent works really well is that the file is downloaded in random order. That's basically true for one client (transmission) - who specifically refuses to allow linear ordering. Most clients implement this. To enable it, its about a 3 sloc change. I hate clients that dont work for the user.

wing-_-nuts 2y ago
>That's basically true for one client (transmission) - who specifically refuses to allow linear ordering. Most clients implement this. Transmission does allow you to set a particular file (let's say the first file in a series) as 'high priority' though so it's not like they don't allow any change to the behavior
- calvinmorrison 2y ago
  good for them. they specifically refuse to implement this feature even though its a tiny change for the 'good of the ecosystem' or something stupid.

HumblyTossed 2y ago

Just for shits and giggles, I wonder if a protocol similar to HLS, where each peer is assigned a segment to transcode / cache, would work for best cases. If a peer drops, that segment is assigned to another peer. Or if there are, say, 5 peers, double up on the next segment to increase odds it will be done. Just a mental curiosity is all.