Question: Why doesn't Close() close the stream?

[prestonvanloon]

I don't understand this bit of the API. When we are handling Closer interfaces, we close them when we are done using the resource. However, this Closer doesn't actually close the stream. It seems we have to call Reset which actually sends an error to the peer.

go-libp2p-core/mux/mux.go

Lines 22 to 24 in bac72eb

	// Close closes the stream for writing. Reading will still work (that
	// is, the remote side can still write).
	io.Closer

We have had some pain with this when trying the following logic:

• Send a message to the peer
• Close the connection because we don't care about the response or if they received it.

For the second step, if we call Reset then the peer will receive the error only and does not process the message. However, if we call Close and the peer doesn't then we have this dangling connection that we don't care about.

[Stebalien]

So, Close currently closes the write half. To close the read half, you need to read the EOF off the stream.

This is clearly not a very nice API and was a terrible mistake. I planned to address this once we merged the go-libp2p-core refractor and now we have.

[marten-seemann]

This is clearly not a very nice API and was a terrible mistake. I planned to address this once we merged the go-libp2p-core refractor and now we have.

I don't think this is a mistake. By the way, this exactly how things work for QUIC streams as well. And for TCP connections, if I remember correctly.

[Stebalien]

The issue is at the API layer, not the protocol layer. That is, users expect Close() to close in both directions and free resources. This is what tcpconn.Close() does. It's also what a close(sock) does in C.

We need to support closing for reading/writing, but we should do the thing users expect by default.

[aschmahmann]

@raulk I see you're the author on the latest version of the PR for this #155. What's the latest state?