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
feat: make Connection::remote_id and Connection::alpn infallible (#3556)
## Description
This PR refactors the connection API to make `Connection::remote_id()`
and `Connection::alpn()` infallible. Previously, these methods could
fail if called before the handshake completed or if the handshake data
was unavailable. Now, `Connection` guarantees that it represents a fully
authenticated connection with verified remote identity and ALPN
protocol, since it now can only be constructed after successful
handshake completion and authentication, eliminating the need for
fallible accessors.
### 0-RTT API Improvements
The 0-RTT API has been restructured with clearer types and semantics:
- Use `Incoming::accept` to return an `Accepting`. Use
`Accepting::into_0rtt` to return an `IncomingZeroRttConnection`
- Use `Connecting::into_0rtt` to return a `OutgoingZeroRttConnection`
- **`OutgoingZeroRttConnection`**: Represents client-side 0-RTT
connections created via `Connecting::into_0rtt()`. Allows sending 0-RTT
data before the handshake completes. Call `handshake_completed()` to get
a `ZeroRttStatus` indicating whether the 0-RTT data was accepted or
rejected by the server.
- **`IncomingZeroRttConnection`**: Represents server-side 0-RTT/0.5-RTT
connections created via `Accepting::into_0rtt()`. Allows receiving 0-RTT
data from clients or sending 0.5-RTT data before the handshake
completes. Call `handshake_completed()` to get a fully authenticated
`Connection`.
- **`ZeroRttStatus` enum**: Returned by
`OutgoingZeroRttConnection::handshake_completed()` to indicate whether
the server accepted or rejected the 0-RTT data:
- `ZeroRttStatus::Accepted(Connection)`: 0-RTT data was accepted,
streams opened before handshake remain valid
- `ZeroRttStatus::Rejected(Connection)`: 0-RTT data was rejected,
pre-handshake streams will error and data must be resent
These types replace the previous the previous version of `Connection` &
the `ZeroRttAccepted` type and provide a more explicit API for handling
0-RTT connection states and outcomes.
### Error Handling
- Connection authentication failures now return `AuthenticationError`
during the conversion between a `quinn:Connection` (which can exist
before the handshake completes) and an `iroh::Connection`. This error
may occur if the remote endpoint is not using the expected TLS
cryptography or if the remote endpoint is a plain quinn connection. You
may also see these errors after calling the `handshake_completed` method
on `IncomingZeroRttConnection` or `OutgoingZeroRttConnection`, if the
connection was closed before the handshake completed.
- New `ConnectingError` type for errors during handshake completion
## Breaking Changes
- `iroh`
- `changed`
- `ConnectError::Connection` - fields changed
- `AcceptError::Connection` - fields changed
- `AcceptError::MissingRemoteEndpointId` - fields changed
- `AcceptError::NotAllowed` - fields changed
- `AcceptError::User` - fields changed
- `Connecting::into_0rtt` -> returns `Result<OutgoingZeroRttConnection,
Connecting>`
- `removed`
- `ProtocolHandler::on_connecting()` removed - implement
`on_accepting()` instead, which takes `Accepting` rather than
`Connecting`
- `DynProtocolHandler::on_connecting()` removed - implement
`on_accepting()` instead
- `iroh::endpoint::IncomingFuture` - use `Accepting` instead
- `iroh::endpoint::ZeroRttAccepted` - replaced by explicit 0-RTT
connection types
---------
Co-authored-by: “ramfox” <“[email protected]”>
Co-authored-by: Philipp Krüger <[email protected]>
Co-authored-by: Frando <[email protected]>
Co-authored-by: Friedel Ziegelmayer <[email protected]>
0 commit comments