How P2P delivery works
MeshStream sits between your player and the media delivery network. For each playback, the SDK creates a session, obtains policy, and chooses the best available source for each segment.
A playback session
- Your application starts a session with an application key, content ID, and playback URL. The service resolves tenant ownership and access-side locality.
- MeshStream validates policy and discovers eligible peers.
- The SDK requests segments from peers when the content and network conditions qualify.
- If a peer is unavailable or too slow, the request falls back to your CDN.
- Session and delivery events are reported for diagnostics and usage.
Two delivery paths
From another device
When another authorized viewer has a compatible segment, the SDK can retrieve it through the P2P path. Peer upload is not metered as MeshStream download quota.
From your CDN
When no peer is suitable, the SDK uses your CDN or configured fallback path. This path is what protects playback continuity when acceleration is unavailable.
What remains yours
Your player continues to manage manifests, ABR, DRM, decoding, and rendering. Origin authorization headers and private tokens must remain on your controlled origin or CDN path and must never be sent to peers.
Rollout guidance
Start with a small application or platform cohort, verify both P2P and forced-CDN playback, then expand using policy and session evidence. P2P should be treated as an enhancement, never as the only playback dependency.
Workload and measurement guides
- P2P CDN for live streaming: evaluate concurrency, reachability, latency, and CDN fallback before expanding a rollout.
- Video CDN cost and offload guide: distinguish delivered bytes from net cost and compare representative workloads.