You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(iroh): remove quinn::Endpoint::wait_idle from iroh::Endpoint::close process (#3165)
## Description
`quinn::Endpoint::wait_idle` adds a minimum 3 second closing time to
`iroh::Endpoint::close` if you have any connections that have not closed
gracefully.
While we *want* users to close connections gracefully, we should also
not be forcing users to wait 3 seconds to close the `iroh::Endpoint` if
a connection has "gone wrong" if they don't want to.
So instead, we are taking out `quinn::Endpoint::wait_idle` and adding
more context for how to close a connection gracefully.
## Notes & open questions
Before 1.0 we will be re-visiting closing to make sure the APIs make
sense.
## Change checklist
- [x] Self-review.
- [x] Documentation updates following the [style
guide](https://rust-lang.github.io/rfcs/1574-more-api-documentation-conventions.html#appendix-a-full-conventions-text),
if relevant.
---------
Co-authored-by: “ramfox” <“[email protected]”>
Copy file name to clipboardExpand all lines: iroh/src/endpoint.rs
+17-19Lines changed: 17 additions & 19 deletions
Original file line number
Diff line number
Diff line change
@@ -991,10 +991,13 @@ impl Endpoint {
991
991
/// of `0` and an empty reason. Though it is best practice to close those
992
992
/// explicitly before with a custom error code and reason.
993
993
///
994
-
/// It will then make a best effort to wait for all close notifications to be
995
-
/// acknowledged by the peers, re-transmitting them if needed. This ensures the
996
-
/// peers are aware of the closed connections instead of having to wait for a timeout
997
-
/// on the connection. Once all connections are closed or timed out, the magic socket is closed.
994
+
/// This will not wait for the [`quinn::Endpoint`] to drain connections.
995
+
///
996
+
/// To ensure no data is lost, design protocols so that the last *sender*
997
+
/// of data in the protocol calls [`Connection::closed`], and `await`s until
998
+
/// it receives a "close" message from the *receiver*. Once the *receiver*
999
+
/// gets the last data in the protocol, it should call [`Connection::close`]
1000
+
/// to inform the *sender* that all data has been received.
998
1001
///
999
1002
/// Be aware however that the underlying UDP sockets are only closed
1000
1003
/// on [`Drop`], bearing in mind the [`Endpoint`] is only dropped once all the clones
@@ -1393,21 +1396,16 @@ impl Connection {
1393
1396
///
1394
1397
/// # Gracefully closing a connection
1395
1398
///
1396
-
/// Only the peer last receiving application data can be certain that all data is
1397
-
/// delivered. The only reliable action it can then take is to close the connection,
1398
-
/// potentially with a custom error code. The delivery of the final CONNECTION_CLOSE
1399
-
/// frame is very likely if both endpoints stay online long enough, calling
1400
-
/// [`Endpoint::close`] will wait to provide sufficient time. Otherwise, the remote peer
1401
-
/// will time out the connection, provided that the idle timeout is not disabled.
1402
-
///
1403
-
/// The sending side can not guarantee all stream data is delivered to the remote
1404
-
/// application. It only knows the data is delivered to the QUIC stack of the remote
1405
-
/// endpoint. Once the local side sends a CONNECTION_CLOSE frame in response to calling
1406
-
/// [`close`] the remote endpoint may drop any data it received but is as yet
1407
-
/// undelivered to the application, including data that was acknowledged as received to
1408
-
/// the local endpoint.
1409
-
///
1410
-
/// [`close`]: Connection::close
1399
+
/// Only the peer last **receiving** application data can be certain that all data is
1400
+
/// delivered.
1401
+
///
1402
+
/// To communicate to the last **sender** of the application data that all the data was received, we recommend designing protocols that follow this pattern:
1403
+
///
1404
+
/// 1) The **sender** sends the last data. It then calls [`Connection::closed`]. This will wait until it receives a CONNECTION_CLOSE frame from the other side.
1405
+
/// 2) The **receiver** receives the last data. It then calls [`Connection::close`] and provides an error_code and/or reason.
1406
+
/// 3) The **sender** checks that the error_code is the expected error code.
1407
+
///
1408
+
/// If the `close`/`closed` dance is not done, or is interrupted at any point, the connection will eventually time out, provided that the idle timeout is not disabled.
0 commit comments