1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
//! Framed and streaming I/O adapters for completion-based transports.
//!
//! This module layers framing and codecs on top of [`crate::io::AsyncRead`] /
//! [`crate::io::AsyncWrite`], using owned buffers suitable for io_uring / IOCP /
//! kqueue completion models.
//!
//! # Overview
//!
//! - [`crate::io::Stream`] / [`crate::io::Sink`]: pure-async stream and sink traits
//! - [`Framer`]: byte-level frame layout (length prefix, delimiters, …)
//! - [`Encoder`] / [`Decoder`]: payload ↔ typed messages
//! - [`FramedRead`] / [`FramedWrite`] / [`Framed`]: combined adapters
//!
//! The buffer type parameter defaults to `Vec<u8>` but is generic over
//! [`crate::buf::IoBufMut`] + [`crate::buf::IoBufMutExt`] so future buffer types
//! (e.g. `bytes::BytesMut`) can plug in without changing codec APIs.
//!
//! # Duplex transports
//!
//! [`Framed`] requires reader and writer halves that can make progress
//! independently. [`crate::tls::ClientTlsStream`] and
//! [`crate::tls::ServerTlsStream`] do not currently provide such halves, so
//! they cannot be used with combined [`Framed`]. A lock-backed split is not a
//! substitute in a completion-based runtime: a pending read would hold the
//! lock across its operation and could prevent a required write indefinitely.
//! Use a directional [`FramedRead`] or [`FramedWrite`] when only one direction
//! is needed. Combined framed TLS requires future TLS-level duplex support.
use ;
pub type PinBoxFuture<T> = ;
pub use ;
pub use ;
pub use ;
pub use ;
pub use ;