Live data from Hacker News

New improvements to IPFS Bitswap for faster container image distribution

blog.ipfs.io

21–30 of 61 posts

Re: New improvements to IPFS Bitswap for faster container image distribution

#21

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.

How does Netflix using IPFS between their servers sacrifice my privacy?

Re: New improvements to IPFS Bitswap for faster container image distribution

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

#23
post #19

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

I would think because IPNS is IPFS.. and you asked how IPNS compares to BitTorrent. Maybe I misunderstand your question, but the reply seems totally on topic and a valid answer to your question.

Re: New improvements to IPFS Bitswap for faster container image distribution

#24
post #19

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

"Inter-Planetary Name System (IPNS) is a system for creating and updating mutable links to IPFS content. Since objects in IPFS are content-addressed, their address changes every time their content does. That's useful for a variety of things, but it makes it hard to get the latest version of something."

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
post #22

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

I don't see why it'd be ordered for blocks received

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

#26
I really don't understand why there is a big hype towards IPFS which is still in development stage although, there are other options which are already out and working like Sia - Skynet which is not even getting a fraction of attention IPFS is getting.

Re: New improvements to IPFS Bitswap for faster container image distribution

#27
post #22

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

Files are not downloaded sequentially, they're chunked into blocks which are sent in parallel.

Re: New improvements to IPFS Bitswap for faster container image distribution

#29
post #4

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

> And you can't share pieces across different torrents

So make each layer an own torrent?

Re: New improvements to IPFS Bitswap for faster container image distribution

#30

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.

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

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.

Post reply on HN