All our operations support cancellation via a CancellationToken.

However, once an operation begins sending or receiving a message over the network we no longer support cancellation until the network I/O completes. It is likely that callers would expect a cancellation request to interrupt the pending network I/O.

The reason we don't support cancellation once network I/O has begun is that we don't want to leave the connection in a damaged state, such as with a half written or half read message. While we don't yet support pipelining (sharing the same connection among multiple tasks), any future support for pipelining would depend on tasks sharing the connection never leaving the connection in a damaged state.

So any implementation of this ticket would have to ensure that cancelling an operation is done in a way that doesn't damage the connection.