31 releases

0.7.0 Oct 26, 2021
0.5.0 Feb 21, 2021
0.4.0 May 17, 2020
0.3.2 Jan 3, 2020
0.1.8 Jun 17, 2017

#753 in Network programming

Download history 2148/week @ 2021-08-10 1830/week @ 2021-08-17 1499/week @ 2021-08-24 1402/week @ 2021-08-31 1614/week @ 2021-09-07 1516/week @ 2021-09-14 1761/week @ 2021-09-21 1313/week @ 2021-09-28 1676/week @ 2021-10-05 2343/week @ 2021-10-12 2039/week @ 2021-10-19 1640/week @ 2021-10-26 1425/week @ 2021-11-02 1938/week @ 2021-11-09 2136/week @ 2021-11-16 2265/week @ 2021-11-23

8,048 downloads per month
Used in 32 crates (20 directly)

MIT/Apache

65KB
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

~6.5–10MB
~265K SLoC