A collection of different transport implementations and related tools focused primarily on web technologies. Features the in-house development of 8 IETF RFCs, 3 formal specifications and several other invented ideas.

Works on embedded devices with heap allocators. If you find this crate interesting, please consider giving it a star ⭐ on GitHub.

Many things that generally improve performance are used in the project, to name a few:

1. Manual vectorization: When an algorithm is known for processing large amounts of data, several experiments are performed to analyze the best way to split loops in order to allow the compiler to take advantage of SIMD instructions in x86 processors.
2. Memory allocation: Whenever possible, all heap allocations are called only once at the start of an instance creation and additionally, stack memory usage is preferably prioritized over heap memory.
3. Fewer dependencies: No third-party is injected by default. In other words, additional dependencies are up to the user through the selection of Cargo features, which decreases compilation times. For example, you can see the mere 13 dependencies required by the PostgreSQL client using cargo tree -e normal --features postgres.

Since memory are usually held at the instance level instead of being created and dropped on the fly, its usage can growth significantly depending on the use-case. If appropriated, try using a shared pool of resources or try limiting how much data can be exchanged between parties.

Checkout wtx-bench to see a variety of benchmarks or feel free to point any misunderstandings or misconfigurations.

There are mainly 2 things that impact performance, the chosen runtime and the number of pre-allocated bytes. Specially for servers that have to create a new instance for each handshake, pre-allocating a high number of bytes for short-lived or low-transfer connections can have a negative impact.

Anything marked with #[bench] in the repository is considered a low-level benchmark in the sense that they measure very specific operations that generally serve as the basis for other parts.

Take a look at https://bencher.dev/perf/wtx to see all low-level benchmarks over different periods of time.

WTX does not have built-in cryptographic algorithms, as such, it is necessary to select a backend when working with X.509 or TLS.

• crypto-aws-lc-rs
• crypto-graviola
• crypto-ring
• crypto-rust-crypto

Calling methods will act as NO-OPs if no backend is selected.

These numbers provide an estimate of the expected waiting times when developing with WTX. If desired, you can compare them with other similar Rust projects through the dev-bench.sh script.

When using a feature that requires network connection, it is often necessary to perform encrypted communication and since WTX is not hard-coded with a specific stream implementation, it is up to you to choose the best TLS provider.

Some utilities like TokioRustlsConnector or TokioRustlsAcceptor are available to make things more convenient but keep in mind that it is still necessary to activate a crate that provides certificates for client usage.

Demonstrations of different use-cases can be found in the wtx-examples directory as well as in the documentation.

• Does not support systems with a pointer length of 16 bits.

• Expects the infallible sum of the lengths of an arbitrary number of slices, otherwise the program will likely trigger an overflow that can possibly result in unexpected operations. For example, in a 32bit system such a scenario should be viable without swap memory or through specific limiters like ulimit.