Skip to main content

moq_net/
lib.rs

1//! # moq-net: Media over QUIC networking layer
2//!
3//! `moq-net` is the networking layer for Media over QUIC: real-time pub/sub with built-in
4//! caching, fan-out, and prioritization, on top of QUIC. Sub-second latency at massive scale.
5//! At session setup it negotiates one of two wire protocols: the simplified `moq-lite`
6//! protocol (the default) or the full IETF `moq-transport` protocol.
7//!
8//! ## API
9//! The API is built around Producer/Consumer pairs, with the hierarchy:
10//! - [Origin]: A collection of [Broadcast]s, produced by one or more [Session]s.
11//! - [Broadcast]: A collection of [Track]s, produced by a single publisher.
12//! - [Track]: A collection of [Group]s, delivered out-of-order until expired.
13//! - [Group]: A collection of [Frame]s, delivered in order until cancelled.
14//! - [Frame]: Chunks of data with an upfront size.
15//!
16//! ## Compatibility
17//! The API exposes the intersection of features supported by both protocols, intentionally
18//! keeping it small rather than polluting it with half-baked features.
19//!
20//! The library is forwards-compatible with the full IETF specification and supports
21//! moq-transport drafts 14+ via version negotiation. Everything will work perfectly,
22//! so long as your application uses the API as defined above.
23//!
24//! For example, there's no concept of "sub-group". When connecting to a moq-transport
25//! implementation, we use `sub-group=0` for all frames and silently drop any received
26//! frames not in `sub-group=0`. If your application genuinely needs multiple sub-groups,
27//! tell me *why* and we can figure something out.
28//!
29//! ## Producers and Consumers
30//! Each level of the hierarchy is split into a Producer / Consumer pair:
31//! - The **Producer** is the writer: it appends new state (publishes a broadcast,
32//!   starts a group, writes frames, closes a track).
33//! - The **Consumer** is a reader: each consumer holds its own independent view
34//!   of the producer's state, with its own cursor through the stream.
35//!
36//! Both halves are cheaply clonable so you can hand out multiple handles. Cloning
37//! a consumer creates another reader (each at its own cursor); cloning a producer
38//! gives another writer that contributes to the same shared state. Closing the
39//! last producer signals consumers that no more updates are coming.
40//!
41//! ## Async
42//! This library is async-first, using [tokio] for async I/O and task management.
43//! Any plain `async` method should be awaited from inside an active tokio runtime.
44//! Otherwise you risk a panic.
45//!
46//! This requirement is being phased out as more methods grow `poll_xxx` counterparts
47//! built on [`conducer`], so you can drive them from custom executors without a tokio
48//! runtime. You can also call them synchronously, since [`conducer`] is built on the
49//! standard [`std::task::Waker`] API and any [`std::task::Waker`] is a valid driver.
50
51mod client;
52mod coding;
53mod error;
54mod ietf;
55mod lite;
56mod model;
57mod path;
58mod server;
59mod session;
60mod setup;
61mod version;
62
63pub use client::*;
64pub use coding::{BoundsExceeded, DecodeError, EncodeError};
65pub use error::*;
66pub use model::*;
67pub use path::*;
68pub use server::*;
69pub use session::*;
70pub use version::*;
71
72// Re-export the bytes crate
73pub use bytes;