Cancellation via RST_STREAM

[dfawley]

Clients and servers must be able to cancel streams:

• Client-side:

  • Cancellation should result in a RST_STREAM frame, and is distinct from closing its send side of the stream (i.e. END_STREAM on a DATA frame).
  • Applications should be able to cause cancellation through some mechanism.
  • Cancellation must automatically propagate from an incoming call to an outgoing call.
  • Cancellation should also occur based on timeout - when the RPC's timeout elapses, RST_STREAM should automatically be sent, and the client should be able to discover this via an RPC status (libraries should drop unread messages; but not strictly required).

• Server-side:

  • Cancellation should result in a RST_STREAM frame, and is distinct from sending the status in a trailing HEADERS frame.
  • Applications should be able to cause cancellation, though it's very low priority if it's actually or ever implemented.
  • Cancellation should occur when the timeout (grpc-timeout header) is reached as with the client. The server application should discover this presumably by having reads and writes on the stream fail.

• And on both sides:

  • If a RST_STREAM is received from the peer, it could be a race between the local timeout and the remote timeout. The local timeout should be checked, and the status should be DEADLINE_EXCEEDED if the local timeout has also elapsed when this occurs, or CANCELLED otherwise. This is important on both sides of the connection, and the server mostly cares because of metrics, so the metrics handlers need to see the result of this fixup.