85% bandwidth consumed by duplicate data

[christroutner]

I've got this IPFS forum thread open, trying to figure out the root cause for why ipfs-coord consumes so much bandwidth.

For the purpose of testing, I upgraded to the latest version of both IPFS and Orbit-DB:

• ipfs v0.61.0
• orbit-db v0.28.0

By running the stats.bw() and bitswap.stat() calls every 5 seconds, I can see that duplicate blocks make up about 85% of the bandwidth of my IPFS node:

{
  ...
  dupBlksReceived: 60517n,
  dupDataReceived: 127019392n,
  dataReceived: 151752023n,
  blocksSent: 7n,
  dataSent: 1050n
}

ipfs-coord makes heavy use of pubsub channels and OrbitDB. On one level, the amount of duplicate data makes sense, since I've got all these instances of OrbitDB out there on the network trying to sync.

But on the other hand, I've got to find some way to reduce all this duplicate data if I hope to grow a network beyond 10 nodes. The bandwidth consumption seems to grow exponentially with the number of nodes in the subnetwork.

This go-ipfs issue documented some significant improvements to reducing duplicate block data. This improvement appears to have landed in go-ipfs, but I'm still trying to figure out if it ever landed in js-ipfs.

Any tips or suggestions on how to reduce duplicate block data? Is anyone else running OrbitDB also experiencing this issue?

[christroutner]

I did a number of things to reduce this bandwidth issue.

• I switched from js-ipfs embedded in my app, to an external go-ipfs node controlled with ipfs-http-client. This allowed me to take advantage of bitswap improvements.

• I also switch to my own private network, which also helped a lot.