[Question] How to properly and quickly end an ongoing `files.get` stream ?

[ya7ya]

• Version: 0.26.0
• Platform: Browser (Chrome)
• Subsystem: files.get , ipfs-bitswap

Type: Question

Severity: Low

Description:

How to properly end an ongoing files stream from files.get ? I already tried end() and destroy() but when looking at the bitswap module. I can still see blocks in the wantlist and blocks being received. So I also tried using _bitswap.unwant(cids) and even went a little deeper and tried ipfs._bitswap.wm.cancelWants(cids) but blocks keep on coming.

So What's the proper way to end the file(s) stream.??

Steps to reproduce the error:

go to example exchange files in browser

add the following after line 85

  node.files.get(multihash, (err, filesStream) => {
    if (err) {
      return onError(err)
    }

    filesStream.on('data', (file) => {
      // stopping stream(s)
     if (file.content) {
       file.content.destroy()
       fileStream.destroy()
       setTimeout(() => {
          node._bitswap.engine.ledgerMap.forEach((ledger, peerId, ledgerMap) => {
             console.log(`${peerId} : ${JSON.stringify(ledger.accounting)}\n`)
          })
      }, 3000)
     }

[daviddias]

There are multiple things there. The first is that there might be indeed a bug that we missed. The second and most important, you gotta remember that when you send a want list to another peer, it opens the space for a block to be sent before your updated want list (with all of the wants) arrive.

This needs better testing at the bitswap level. go-ipfs has so good bitswap tests, wanna help us port them over? https://github.com/ipfs/go-ipfs/blob/master/exchange/bitswap/bitswap_test.go

[ya7ya]

hey @diasdavid , Thanks for clarifying that. About the second point, I thought when you send cancelWants the peer doesn't send the blocks that hasn't already been sent. or does it handle the wantlist as 1 order and sends the wantlist before processing the new want (or unwant in this case) list ??

Yes, I'm already knee-deep in bitswap so I'll take a look at the go-ipfs tests and try to port it to js-ipfs-bitswap 👍

[daviddias]

the peer doesn't send the blocks that hasn't already been sent. or does it handle the wantlist as 1 order and sends the wantlist before processing the new want (or unwant in this case) list ??

It just happens due to network io. A block being sent might happen at the same time as a request being canceled. This is not a bug of functionality, but better heuristics can help improve perf and mem management.

I'll take a look at the go-ipfs tests and try to port it to js-ipfs-bitswap 👍

Fantastic! Thank you, @ya7ya :)

[daviddias]

@ya7ya is there still a value on keeping this one open?

[ya7ya]

@diasdavid No. You can go ahead and close this. 👍