error codes: provide error codes on stream reset and connection close #623
Conversation
error-codes/README.md
Outdated
| In the event that a node detects violation of a protocol or is unable to | ||
| complete the necessary steps required for the protocol, it's useful to provide a | ||
| reason for disconnection to the other end. This error code can be sent on both |
There was a problem hiding this comment.
It's broader than this. This doesn't only apply to protocol violations (which should be rare), but also to common events like running into resource limits, connections being pruned by the connection manager, etc.
There was a problem hiding this comment.
I've rephrased this and removed the specific reference to protocol errors.
sukunrt
force-pushed
the
error-codes
branch
from
3b23cde
to
070f090
Compare
Do we need to? Application protocols can have conflicting error codes. From the application context, it's clear which is the relevant error. I am planning to reserve a space for libp2p to use for its errors and let applications do whatever they like with the application error codes space. |
They're not conflicting, since the application protocol is negotiated during the QUIC handshake.
This is not correct, thanks to multistream. |
sukunrt
force-pushed
the
error-codes
branch
from
d0db0b2
to
3060cd0
Compare
|
I see. All connections are just libp2p connections and they can speak multiple application protocols any of which may close the underlying connection on error. |
sukunrt
force-pushed
the
error-codes
branch
3 times, most recently
from
196f49e
to
168a610
Compare
sukunrt
requested review from
MarcoPolo,
achingbrain,
yiannisbot,
marten-seemann and
jxs
| ``` | ||
|
|
||
| ### Multistream Select | ||
| Multistream-Select is used to negotiate Security protocol for TCP connections before a stream muxer has been selected. There's only one error code defined for such cases, `PROTOCOL_NEGOTIATION_FAILED`. To encode this error, send the string `101` prefixed with the length and close the TCP connection. |
There was a problem hiding this comment.
This is not too useful. The most common case here is a server rejecting a connection because the handling it exceeds some resource limit. In such cases Writing on the connection and closing will cause the write to be dropped because almost certainly there will be unread data in the read buffer.
No description provided.