Module tokio_client 

Available on crate feature tokio only.

TokioClient — a tokio + reqwest IO adapter driving crate::client::HlsClient over real HTTP (issue #717 slice 5).

Feature-gated behind tokio (NOT default): the sans-IO core in engine.rs has zero dependency on tokio, reqwest, a socket, or a clock — this module is a thin async shell that performs the actual HTTP GETs the core’s crate::client::Actions describe (playlist reload, incl. blocking _HLS_msn/_HLS_part; resource fetch, incl. Range byte-ranges) and feeds the responses back into the core, looping until the caller stops polling or the stream ends.

Auth

TokioClientConfig::auth takes a broadcast_auth::Credentials — the same shared scheme-agnostic model rtsp-runtime and multimux’s HTTP input adapters (source::http_auth) use (issue #663 P3b/P3c). Basic (RFC 7617) and Bearer (RFC 6750) are pre-applied on every request via reqwest’s own request-builder helpers (RequestBuilder::basic_auth/ bearer_auth) — no challenge round-trip needed. Digest (RFC 7616) is not something reqwest supports natively: the first request for a given resource is sent bare, and only if the server answers 401 with a WWW-Authenticate challenge does TokioClient compute the Authorization response via broadcast_auth::Authenticator and resend once — the resulting authenticator is then cached and applied preemptively to every subsequent request for as long as it keeps being accepted (RFC 7616 §3.3’s nc advances across those calls), so a live pull doesn’t round-trip a fresh challenge on every single fetch.

Error recovery

• A resource (init/part/segment) fetch that keeps failing is retried up to TokioClientConfig::max_resource_retries times with capped exponential backoff, then crate::client::HlsClient::on_error is called and the adapter moves on — the sans-IO core un-marks that resource as “requested”, so the next playlist reload naturally re-requests it (see engine.rs’s on_error docs). One flaky fetch never stalls the whole client.
• A playlist reload has no such fallback in the sans-IO core — unlike a resource, crate::client::HlsClient::on_error with None does not re-queue anything (there is no “next reload” to fall back to; the current reload IS the mechanism that discovers what to fetch next). So a playlist fetch is retried indefinitely with capped backoff (TokioClientConfig::retry_backoff/TokioClientConfig::max_retry_backoff) rather than ever giving up — a caller wanting a hard ceiling on how long TokioClient::next_output may block should wrap it in tokio::time::timeout itself.

Structs

TokioClient

An async shell driving crate::client::HlsClient over real HTTP.

TokioClientConfig

Tunables for TokioClient. Default gives sane values for a well-behaved LL-HLS origin reachable over a real (or loopback) network.

TokioClientStats

Diagnostic counters for what TokioClient has actually done — distinguishing “parsed an LL-HLS tag” from “acted on it”, the same bar this crate’s own acceptance tests hold the adapter to (issue #717’s “blocking-reload + preload-hint prefetch actually exercised” acceptance item). Also useful to a real caller for observability.

Enums

TokioError

Errors from the tokio IO adapter itself — distinct from crate::client::Error, the sans-IO core’s own parse/demux error type (wrapped here via TokioError::Client).