Close streams when done with them

[Stebalien]

Our stream muxers all support half-open connections. Therefore, if you receive an EOF on a stream, you must send an EOF on that stream to fully close it. Otherwise, the other end will (if correctly implemented) sit around waiting for the EOF.

I know that the part of bitswap that accepts blocks from peers isn't doing this and I wouldn't be surprised if this doesn't happen in other places as well (stream closing has been a persistent problem in go-ipfs as well).

This showed up in ipfs/interop#28.

[Stebalien]

This should probably be difficulty:easy. js-ipfs just needs to close the stream when done.

[daviddias]

@Stebalien I'm pretty sure we always close when done. Couldn't find any location where that is not happening.

[Stebalien]

You sure you don't need something like:

diff --git a/src/network.js b/src/network.js
index 0e914c5..ae91bfa 100644
--- a/src/network.js
+++ b/src/network.js
@@ -81,6 +81,7 @@ class Network {
         if (err) {
           this.bitswap._receiveError(err)
         }
+        pull(pull.empty(), conn)
       })
     )
   }

We have a duplex stream so we can't just read until the end, we have to tell the other side that we aren't sending anything (unless pull does this under the covers...).

[SgtPooki]

js-ipfs is being deprecated in favor of Helia. You can #4336 and read the migration guide.

Please feel to reopen with any comments by 2023-06-02. We will do a final pass on reopened issues afterwards (see #4336).

@achingbrain are we doing this properly in libp2p (with test)? do we need to migrate this to libp2p?

[achingbrain]

I'm not sure that this is an issue, you can watch the number of open streams on a given connection with Graphana and @libp2p/interface-metrics and it doesn't grow over time.

I'm going to close this but it can be reopened against ipfs-bitswap if anything turns up.