Struct Connecting

pub struct Connecting { /* private fields */ }

In-progress connection attempt future

Implementations

impl Connecting

pub fn into_0rtt(self) -> Result<(Connection, ZeroRttAccepted), Self>

Convert into a 0-RTT or 0.5-RTT connection at the cost of weakened security

Returns Ok immediately if the local endpoint is able to attempt sending 0/0.5-RTT data. If so, the returned Connection can be used to send application data without waiting for the rest of the handshake to complete, at the cost of weakened cryptographic security guarantees. The returned ZeroRttAccepted future resolves when the handshake does complete, at which point subsequently opened streams and written data will have full cryptographic protection.

Outgoing

For outgoing connections, the initial attempt to convert to a Connection which sends 0-RTT data will proceed if the crypto::ClientConfig attempts to resume a previous TLS session. However, the remote endpoint may not actually accept the 0-RTT data–yet still accept the connection attempt in general. This possibility is conveyed through the ZeroRttAccepted future–when the handshake completes, it resolves to true if the 0-RTT data was accepted and false if it was rejected. If it was rejected, the existence of streams opened and other application data sent prior to the handshake completing will not be conveyed to the remote application, and local operations on them will return ZeroRttRejected errors.

A server may reject 0-RTT data at its discretion, but accepting 0-RTT data requires the relevant resumption state to be stored in the server, which servers may limit or lose for various reasons including not persisting resumption state across server restarts.

If manually providing a crypto::ClientConfig, check your implementation’s docs for 0-RTT pitfalls.

Incoming

For incoming connections, conversion to 0.5-RTT will always fully succeed. into_0rtt will always return Ok and the ZeroRttAccepted will always resolve to true.

If manually providing a crypto::ServerConfig, check your implementation’s docs for 0-RTT pitfalls.

Security

On outgoing connections, this enables transmission of 0-RTT data, which is vulnerable to replay attacks, and should therefore never invoke non-idempotent operations.

On incoming connections, this enables transmission of 0.5-RTT data, which may be sent before TLS client authentication has occurred, and should therefore not be used to send data for which client authentication is being used.

pub async fn handshake_data(&mut self) -> Result<Box<dyn Any>, ConnectionError>

Parameters negotiated during the handshake

The dynamic type returned is determined by the configured Session. For the default rustls session, the return value can be downcast to a crypto::rustls::HandshakeData.

pub fn local_ip(&self) -> Option<IpAddr>

The local IP address which was used when the peer established the connection

This can be different from the address the endpoint is bound to, in case the endpoint is bound to a wildcard address like 0.0.0.0 or ::.

This will return None for clients, or when the platform does not expose this information. See quinn_udp::RecvMeta::dst_ip for a list of supported platforms when using quinn_udp for I/O, which is the default.

pub fn remote_address(&self) -> SocketAddr

The peer’s UDP address.

Will panic if called after poll has returned Ready.

Trait Implementations

impl Debug for Connecting

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Future for Connecting

type Output = Result<Connection, ConnectionError>

The type of value produced on completion.

fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>

Attempts to resolve the future to a final value, registering the current task for wakeup if the value is not yet available.