TIMEOUT CONNECTION_CLOSE error

[rpaulo]

Perhaps we should have a TIMEOUT error code? Connection timeouts are extremely common. It would help implementations detect timeout conditions without having to parse the connection_close error string. One could argue that a timeout isn't an error, but we already have SERVER_BUSY.

[mikkelfj]

If so, it should probably distinguish between idle timeout and handshake timeout.

[ianswett]

I think the transport doc currently suggests using NO_ERROR. There are no other suggested uses of NO_ERROR, so this seems like it is functionally equivalent to a TIMEOUT error code?

After receiving a CONNECTION_CLOSE frame, endpoints enter the draining state. An endpoint that receives a CONNECTION_CLOSE frame MAY send a single packet containing a CONNECTION_CLOSE frame before entering the draining state, using a CONNECTION_CLOSE frame and a NO_ERROR code if appropriate. An endpoint MUST NOT send further packets, which could result in a constant exchange of CONNECTION_CLOSE frames until the closing period on either peer ended.

[rpaulo]

@ianswett When I read that, it doesn't really sound like it's describing a timeout condition, just that one side is about to enter the draining state and it may send a CONNECTION_CLOSE packet to increase the chances the other side also moves to the draining state.

NO_ERROR doesn't seem that useful to me.

[marten-seemann]

If my understanding of the spec is correct, you're not supposed to send a CONNECTION_CLOSE when you detect a timeout, since you don't expect it to be received anyway.

[rpaulo]

I was thinking about the case where the idle timeout is long and a peer would be stuck retransmitting data until it hits the idle timeout. Right now, it can send NO_ERROR, but it just seems like having a specific error code for timeouts would help. I agree that there's no need to send anything after we reach the idle timeout.

[ianswett]

I prefer more error codes over fewer, especially for cases like this that may be quite common.

Even if we use NO_ERROR, I think we should specify what the error code to send is in the case you're mentioning.

[martinthomson]

Why would this condition need to be signaled?

[rpaulo]

@martinthomson I think it could help identify problems when the link is asymmetrically broken and you don't have access to the state of the server.

[larseggert]

Discussed in ZRH. Proposed resolution is to close with no action.