Delay marking connection as .ready until receiving initial settings f… #529
Conversation
|
Fixes #519 |
MrMage
left a comment
MrMage
left a comment
There was a problem hiding this comment.
Is this something we should have tests for?
| /// ▲ | | ||
| /// HTTP2Frame│ │HTTP2Frame | ||
| /// ┌─┴───────────────────────▼─┐ | ||
| /// ┌──────────────────────────┐ |
There was a problem hiding this comment.
Should we also add the source files for these diagrams to version control at some point?
There was a problem hiding this comment.
This is it I'm afraid! I created them with Monodraw originally and have just updated them manually since 😬
Pretty sure you can paste ASCII-art back into Monodraw though so it shouldn't be a problem.
…rame Motivation: It is possible for a connection to be immediately closed by the remote after a successful TLS handshake. In this case, the connection would be marked as ready and any backoff would be reset. That is, a reconnection attempt would be made immediately and the cycle would repeat. The gRPC core lib suggests resetting backoff after the initial settings frame has been made. Modifications: Add a handler which on observing the initial settings frame: 1. marks the connectivity as ready and, 2. removes itself from the pipeline. The client connection diagram was also updated to reflect this. Result: The connectivity state will only be marked as ready once the settings frame has been received from the peer.
Ideally, yes. Realistically I think the only thing we can test for here is that the client doesn't become ready before receiving the settings frame and I'm not sure how much value there is in that, WDYT? |
|
Yeah, I wasn't sure about that myself, so let's not test this. Once you update the conflicts I'll merge :-) And if you do that in the next hour and ping me I can even cut a release ;-) |
2 participants
…rame
Motivation:
It is possible for a connection to be immediately closed by the remote
after a successful TLS handshake. In this case, the connection would be
marked as ready and any backoff would be reset. That is, a reconnection
attempt would be made immediately and the cycle would repeat. The gRPC
core lib suggests resetting backoff after the initial settings frame has
been made.
Modifications:
Add a handler which on observing the initial settings frame:
The client connection diagram was also updated to reflect this.
Result:
The connectivity state will only be marked as ready once the settings
frame has been received from the peer.