Struct Connecting 

pub struct Connecting { /* private fields */ }

Available on crate features quic and std only.

In-progress connection attempt future

Implementations

impl Connecting

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

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 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 Ok(true) if the 0-RTT data was accepted and Ok(false) if it was rejected. A failed handshake returns Err with the connection error. 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.

Whether the attempt offers 0-RTT at all follows the ClientConfig it was made with: TlsOptions::with_early_data governs it, and it is off by default.

Incoming

Incoming connections permit a 0.5-RTT handle. The ZeroRttAccepted future resolves to Ok(true) after a successful handshake or Err if authentication or the connection fails.

Whether the server accepts 0-RTT follows the ServerConfig it was built with, through the same TlsOptions setting.

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<HandshakeSummary, ConnectionError>

What the handshake settled: the application protocol both sides agreed on, and the name the client sent, as HandshakeSummary carries them.

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 rama_udp::DatagramCapabilities::receive_local_ip for platform support.

Will panic if called after poll has returned Ready.

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<(), Error>

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 Connecting>, cx: &mut Context<'_>, ) -> Poll<<Connecting as Future>::Output>

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