Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Use immediate close for application close #854

Closed
martinthomson opened this issue Oct 10, 2017 · 3 comments · Fixed by #855
Closed

Use immediate close for application close #854

martinthomson opened this issue Oct 10, 2017 · 3 comments · Fixed by #855
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.

Comments

@martinthomson
Copy link
Member

At the Seattle interim we concluded that it was important to signal a close to intermediaries (those that have the keys, that is). This allows application endpoints to reach an agreed close state and then terminate the transport without leaving the middlebox on a timer.

In short, once the application protocol has reached a terminal state, it will signal using APPLICATION_CLOSE (some code, maybe NO_ERROR).
@martinthomson martinthomson added -transport design An issue that affects the design of the protocol; resolution requires consensus. labels Oct 10, 2017
martinthomson added a commit that referenced this issue Oct 10, 2017
@martinthomson
Remove application close
0ab0907 
As agreed, this moves the graceful shutdown under the banner of an immediate
close.  That is, the application protocol negotiates a shutdown.  Once the
agreed state has been reached, endpoints send APPLICATION_CLOSE and we are
done.

Closes #854.
@martinthomson martinthomson mentioned this issue Oct 10, 2017
Merged
@RyanTheOptimist
Copy link
Contributor

Does this preclude silent close?

@martinthomson
Copy link
Member Author

I think that the sort of close you have in mind relies on the timeout. That is, neither side explicitly closes the connection, but they just don't get back to it.

What this covers is more the case where you have agreed to finish a certain set of requests - for example - and you are probably actively exchanging data up to the point where you are done. This says that if you want to drop the idle timer, you need to send a message (see the issue for more discussion on why that might be needed).

@RyanTheOptimist
Copy link
Contributor

Gotcha. Thanks!

@mnot mnot added has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. and removed has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. labels Mar 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Remove application close quicwg/base-drafts
3 participants
@martinthomson @mnot @RyanTheOptimist