Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
srt-rs
| OS | Status |
|---|---|
| Linux | |
| macOS | |
| Windows |
NOTE: THIS IS NOT PRODUCTION READY.
Pure rust implementation of SRT (Secure Reliable Transport), without unsafe code.
Reference implementation is available at https://github.com/haivision/srt
Features
- Fast (heap allocations are rare, uses async IO)
- Full safety garuntees of rust
What works
- Listen server connecting
- Client (connect) connecting
- Rendezvous connecting
- Receiving
- Sending
- Special SRT packets (partial)
- Actual SRT (TSBPD)
- Timestamp drift recovery (not throughly tested)
- Congestion control
- Encryption
- Bidirectional
Thread Efficiency
The reference implementation of SRT requires 3 threads per sender and 5 threads per receiver.
With srt-rs, you can assign as many connections to exactly as many threads as you want (usually as many as you have cores) using tokio's futures scheduling. This should allow for handing of many more connections.
Examples
Generate and send SRT packets
cargo run --example sender
Receive SRT packets
cargo run --example receiver
Structure
This repository is structured into 3 crates:
srt-protocol: State machines for the SRT protocol, with no dependencies on futures or tokio. Someday, I would like this to be a no-std crate. I expect this to have frequent breaking changes.srt-tokio: Tokio elements written on top of the protocol, expected to be a relatively stable API.srt-transmit: A srt-live-tranmsit replacement written ontop ofsrt-tokio