191–200 of 231 posts
Earlier quoted context omitted.
Sounds like a recipe for dissatisfied users "Why's my internet slow? Oh, YouTube is uploading a bunch of stuff to other people" "How did I hit my bandwidth cap for the month already? Oh, youtube is..."
Those problems are implementation specific
Earlier quoted context omitted.
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?
> 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 sav…
Unless you use public key cryptography, which is so expensive that nobody actually uses it for arbitrarily large inputs.
Lots of technical discussions - but the real answer is that bittorrent/P2P was displaced by Netflix for all but a small number of hard-core users. That, combined with legal threats, and that p2p required volume/scale to work well, meant that the critical mass died. It was a sad day that we, the users of the internet, en-mass exchanged bittorrent for streaming companies.
* Asymmetric network links, slow upload especially on cellular
* Traffic package limitations, and both DL and UL are counted
* Some ISP are very against p2p, sometimes it's a government policy (China banned "Residential CDNs")
* NAT
you can install Qbittorrent client, after loading torrent file/magnet link, right click on that torrent and click on Download in sequential order. torrent PROTOCOL does not require to download random pieces, in random order. ONLY bittorrent, inc. COMPANY which releases "Utorrent" and "Bittorent" NAMED APPLICATIONS/PROGRAMS does not want legal trouble from media/music companies. Because STREAMING is other legal catego…
Earlier quoted context omitted.
With streaming, the service provider is generally also controlling the clients, so they should be much better off when it comes to client behavior. In case of bring-your-own-client, the incentives are exactly the same: Clients would likely default to good behavior as network health equals user experience, and exactly like BitTorrent there will be neither punishment nor need for it if some clients disobey.
> exactly like BitTorrent there will be neither punishment nor need for it if some clients disobey. "Punishment" (tit-for-tat algorithm) is one of the defining features of bit torrent, especially in comparison to what came before it.
The original spec for the original client allocated a portion of its bandwidth to random peers instead of known-good/preferred peers, so if you had no chunks you were basically bandwidth and/or peer restricted.
If you take the arch linux ISO right now and put it into aria2c to be a new, unknown client with no data to offer, you'll find that while it takes a few seconds to join the network, fetch metadata and connect to peers, you'll quickly saturate your connection completely without ever uploading a single byte.
If you wanted, a streaming network could use direct access or low-hop access as seeding incentive - seed to get slightly lower content latency. When the streaming client is controlled by the content provider, seeding is easily forced and topology could be controlled centrally.
Earlier quoted context omitted.
With streaming, the service provider is generally also controlling the clients, so they should be much better off when it comes to client behavior. In case of bring-your-own-client, the incentives are exactly the same: Clients would likely default to good behavior as network health equals user experience, and exactly like BitTorrent there will be neither punishment nor need for it if some clients disobey.
In video streaming the client really controls everything...unless you have your own client and customize its behavior. You should see how people try and get HLS to pick a stream. With the default players it's not possible - the client does it.
The server can control the stream by advertising a customized manifest to individual clients, although it's a bit silly. HLS is designed to be extremely easy to load distribute and throw CDN/cache proxies in front, and it's a bad sad that content providers are this bad at load management. :/
Either way, the assumption here is that you would swap out the client doing HLS with a client designed to use a P2P protocol, including the seeding portion and network health management.
There was Joost in 2008, from Skype founders. Skype was originally P2P until Microsoft acquisition and killing this legally questionable feature - need to feed the big brother (: Joost raised ~$50M. I remember it as it was one of rare apps built in XUL, the same framework as Mozilla apps (Firefox). https://en.m.wikipedia.org/wiki/Joost
I am a contributor to Iroh ( https://github.com/n0-computer/iroh ), an open source library for direct QUIC connections between devices that can be behind a NAT. Our library is general purpose and can be used whenever you need direct connections, but on top of Iroh we also provide iroh-blobs, which provides BLAKE3 verified streaming over our QUIC connections. Blobs currently is a library that provides low level primit…