33 releases (8 breaking)

0.9.0 Apr 28, 2022
0.7.0 Oct 26, 2021
0.5.0 Feb 21, 2021
0.4.0 May 17, 2020
0.1.8 Jun 17, 2017

#2 in #tls-acceptor

Download history 5163/week @ 2023-12-06 6076/week @ 2023-12-13 3375/week @ 2023-12-20 4571/week @ 2023-12-27 4672/week @ 2024-01-03 5257/week @ 2024-01-10 4172/week @ 2024-01-17 3772/week @ 2024-01-24 4306/week @ 2024-01-31 4847/week @ 2024-02-07 6307/week @ 2024-02-14 5281/week @ 2024-02-21 4555/week @ 2024-02-28 3312/week @ 2024-03-06 4004/week @ 2024-03-13 3375/week @ 2024-03-20

15,882 downloads per month
Used in 41 crates (25 directly)

MIT/Apache

66KB
1.5K SLoC

GitHub Workflow Status License crates.io

tls-api

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

~11–24MB
~431K SLoC