1 unstable release

0.11.0 May 7, 2024

#676 in Asynchronous

Download history 162/week @ 2024-07-19 72/week @ 2024-07-26 93/week @ 2024-08-02 137/week @ 2024-08-09 149/week @ 2024-08-16 375/week @ 2024-08-23 859/week @ 2024-08-30 600/week @ 2024-09-06 460/week @ 2024-09-13 675/week @ 2024-09-20 914/week @ 2024-09-27 798/week @ 2024-10-04 999/week @ 2024-10-11 826/week @ 2024-10-18 668/week @ 2024-10-25 1101/week @ 2024-11-01

3,758 downloads per month
Used in 13 crates (8 directly)

MIT/Apache

68KB
1.5K SLoC

tls-api-2

This is a fork of tls-api with updated dependencies.

Implementation neutral common denominator TLS API.

A library working with TLS can be written with this crate independently on actual TLS implementation, and the user of the library can fill in the actual type implementation.

This crate only provide interfaces: acceptor and connector.

Tokio or async-std

This crate (and dependent tls-api-* crates) have two mutially exclusive features:

  • runtime-tokio implements API over tokio
  • runtime-async-std implements API over async-std

Static or dynamic

API is provided in static or dynamic flavors.

tls_api::TlsAcceptor and tls_api::TlsConnector type are Sized, each function or structure using them need to be parameterized by these types, for example:

async fn create_listener<C: tls_api::TlsAcceptor>()
    -> anyhow::Result<tls_api::TlsStream<async_std::net::TcpStream>>
{ ... }

Alternatively, there's a dynamically-dispatched version of the functions: tls_api::TlsAcceptorType and tls_api::TlsConnectorType. These types are not sized. Could be used like this:

async fn create_listener(acceptor: &tls_api::TlsAcceptorType)
    -> anyhow::Result<tls_api::TslStreamBox>
{ ... }

Note create_listener does not have a type parameter, which makes coding slightly easier at cost of somewhat decreased performance.

Dependencies

~2–12MB
~162K SLoC