Struct Connecting 

pub struct Connecting { /* private fields */ }

In-progress connection attempt future

Implementations

impl Connecting

pub fn into_0rtt(self) -> Result<Connection, 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 Connection::authenticated 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 ZeroRttRejected errors on stream I/O methods, which may arise when the handshake completes. If 0-RTT was rejected, the existence of streams opened and other application data sent by a client prior to the handshake completing will not be conveyed to the remote application. Clients which need to e.g. re-transmit rejected stream data must take care to detect ZeroRttRejected errors even on finished streams opened during 0-RTT, e.g. by awaiting an application-layer response on bidirectional streams, or awaiting SendStream::stopped on unidirectional streams.

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 succeed.

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.

This operation is cancel-safe.

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 udp::RecvMeta::dst_ip for a list of supported platforms when using the default udp I/O backend.

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

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.