bitswap is 'requesting one block at a time'

[daviddias]

In an experiment to fetch orbit (700Mb), js-ipfs hung at 650KiB, checking bitswap wantlist showed that bitswap is only requesting a block at a time.

[dignifiedquire]

Working on this, including some fixes need to be made to files.get

[dignifiedquire]

Short update while I am head down in this:

• Parallelised the block requests in ipfs-unixfs-engine, fixing the original issue mentioned here, that only a single block would be requested at once. (See fix(exporter): add some parallel fetching of blocks where possible ipfs-inactive/js-ipfs-unixfs-engine#73)
• While testing found a bug in js-ipfs-api, for get which resulted in not properly handling more than one or two files. I was able to fix this as well. (See fix(get): properly handled nested content ipfs-inactive/js-ipfs-http-client#384)
• Fixed the code in cli/commands/files/get.js to actually store files and directories to disk as expected. (See Fix/files get #499)
• Now working on actual issues inside bitswap. The current problem is that after receiving some blocks things come to a halt, and it never finishes.

[dignifiedquire]

Found some more details.

• Sometimes js-ipfs will request a hash from go-ipfs that go-ipfs does not know about, even though the whole requested object was added on go-ipfs, so where are those coming from?

[dignifiedquire]

Most of the time, it will just stop, with one or two entries in the wantlist and never receive them from go-ipfs, even though the entry is in the wantlist from go

[dignifiedquire]

Not a bug in bitswap anymore. For details on interop transfer issues see: libp2p/js-libp2p-spdy#48