34 releases

0.12.0 Nov 25, 2024
0.9.0 Apr 28, 2022
0.8.0 Apr 28, 2022
0.7.0 Oct 26, 2021
0.1.8 Jun 17, 2017

#117 in Asynchronous

Download history 6970/week @ 2024-08-17 6897/week @ 2024-08-24 6981/week @ 2024-08-31 7121/week @ 2024-09-07 6900/week @ 2024-09-14 5577/week @ 2024-09-21 6848/week @ 2024-09-28 6522/week @ 2024-10-05 6386/week @ 2024-10-12 5260/week @ 2024-10-19 5798/week @ 2024-10-26 5682/week @ 2024-11-02 4895/week @ 2024-11-09 4435/week @ 2024-11-16 4398/week @ 2024-11-23 5739/week @ 2024-11-30

20,401 downloads per month
Used in 40 crates (25 directly)

MIT/Apache

67KB
1.5K SLoC

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

~2–12MB
~162K SLoC