Saving Netflix's bandwith costs by sacrificing your privacy. IPFS and bittorrent don't do anything to protect the data you are uploading and your IP address. Case in point: https://iknowwhatyoudownload.com/en/peer/ Now every website you visit, any ad/tracker, any homecalling phone app can tell what movies and contents you watch and when you are at home. For years.
New improvements to IPFS Bitswap for faster container image distribution
21–30 of 61 posts
Re: New improvements to IPFS Bitswap for faster container image distribution
#22Trying to recall how the protocol works. Doesn’t this pattern of behavior mean that a lot of machines will end up with the beginning of a file and few will have the end? It sounds like the start of downloading would be very fast and the end would slow down while it hunts for a source
May be why this is only 20% faster than Dockerhub.
Re: New improvements to IPFS Bitswap for faster container image distribution
#23Earlier quoted context omitted.
You can't update a torrent, if the content changes you have to create a new one. IPNS helps with that. And you can't share pieces across different torrents, if some still have the old torrent, they share it separately from the new one even if the differences are minimal.
The article doesn't mention IPNS at all, nor does it talk about the need for mutating an image while it is being shared, so I'm not sure why you think IPNS is even desirable in this use-case?
Re: New improvements to IPFS Bitswap for faster container image distribution
#24Earlier quoted context omitted.
You can't update a torrent, if the content changes you have to create a new one. IPNS helps with that. And you can't share pieces across different torrents, if some still have the old torrent, they share it separately from the new one even if the differences are minimal.
The article doesn't mention IPNS at all, nor does it talk about the need for mutating an image while it is being shared, so I'm not sure why you think IPNS is even desirable in this use-case?
https://docs.ipfs.io/guides/concepts/ipns/
TLDR IPNS are pointers to IPFS content (ie "latest"). If you're tracking your containers and pinning to their versions elsewhere, might not need IPNS.
Re: New improvements to IPFS Bitswap for faster container image distribution
#25> The node sends out a want for each CID to several peers in the session in parallel, because not all peers will have all blocks. If the node starts receiving a lot of duplicate blocks, it sends a want for each CID to fewer peers. If the node gets timeouts waiting for blocks, it sends a want for each CID to more peers. Trying to recall how the protocol works. Doesn’t this pattern of behavior mean that a lot of machin…
If I remember correctly, a node with a full file will send out the blocks in parallel, so leechers should receive blocks effectively in random order
The only reason for some machines having only the start versus the end would be implementation-wise, where maybe you see the want list ordered, and the seeder responds by only shipping the first n blocks it reads in the want list
If the seeder responds with random ordering, you'd avoid the problem of all leechers all having the same blocks
Re: New improvements to IPFS Bitswap for faster container image distribution
#26Re: New improvements to IPFS Bitswap for faster container image distribution
#27> The node sends out a want for each CID to several peers in the session in parallel, because not all peers will have all blocks. If the node starts receiving a lot of duplicate blocks, it sends a want for each CID to fewer peers. If the node gets timeouts waiting for blocks, it sends a want for each CID to more peers. Trying to recall how the protocol works. Doesn’t this pattern of behavior mean that a lot of machin…
Re: New improvements to IPFS Bitswap for faster container image distribution
#28How do you do this? Exercise for the reader? :)
For the case of distributing containers in a datacenter with P2P, theres also this work:
Re: New improvements to IPFS Bitswap for faster container image distribution
#29Would be curious to know how using IPFS for internal container distribution compares to using BitTorrent. IIRC BitTorrent has found similar uses in the past. Also, how well does BitSwap work when the underlying network is congested? Do IPFS nodes do any kind of congestion control?
You can't update a torrent, if the content changes you have to create a new one. IPNS helps with that. And you can't share pieces across different torrents, if some still have the old torrent, they share it separately from the new one even if the differences are minimal.
So make each layer an own torrent?
Re: New improvements to IPFS Bitswap for faster container image distribution
#30Saving Netflix's bandwith costs by sacrificing your privacy. IPFS and bittorrent don't do anything to protect the data you are uploading and your IP address. Case in point: https://iknowwhatyoudownload.com/en/peer/ Now every website you visit, any ad/tracker, any homecalling phone app can tell what movies and contents you watch and when you are at home. For years.
> IPFS and bittorrent don't do anything to protect the data you are uploading and your IP address.
And Netflix are using it across AWS for distributing container images, not touching client devices, unless you know something more than what the article says.
This doesn't have anything to do with customer's privacy.