#async-io #async-read #serialize-deserialize #channel #async-write #message-format #future

async-io-typed

Adapts any AsyncRead or AsyncWrite type to send serde compatible types

7 stable releases

3.0.0 Jan 29, 2023
2.0.0 Jan 23, 2023
1.0.4 Jan 2, 2023
1.0.3 Jan 1, 2023
1.0.2 Dec 30, 2022

#791 in Encoding


Used in async-io-converse

MIT/Apache

73KB
1.5K SLoC

async-io-typed Build Status Latest Version

Documentation

Combines bincode and futures to adapt any AsyncRead or AsyncWrite type into a channel for transmission of serde compatible Rust types.

Who needs this?

If you have an endpoint you need to communicate with and

  • You can establish some kind of I/O connection to it (i.e. TCP, named pipes, or a unix socket)
  • You need clear message boundaries
  • You're not trying to conform to an existing wire format such as HTTP or protobufs. This crate uses a custom format.
  • The data you wish to send can be easily represented in a Rust type, and that type implements serde's Deserialize and Serialize traits.

Then this crate might be useful to you!

Who doesn't need this?

If the endpoint is in the same process then you should not use this crate. You're better served by existing async mpsc channels. Many crates provide async mpsc channels, including futures and tokio. Pick your favorite implementation. Additionally, if you're trying to interface with a process that doesn't have Rust code, and can't adopt a Rust portion, this crate will hurt much more than it will help. Consider using protobufs or JSON if Rust adoption is a blocker.

Binary format

Details on the binary format used by this crate can be found in the binary format specification.

Dependencies

~1.2–2MB
~44K SLoC