Erfahrungsbericht von Tonari zur Umsetzung von „Echtzeit“-Videokonferenzen
→ Die Latenz von Zoom und WebRTC liegt bei 315–500 ms
Um eine echtzeitnahe Latenz von 130 ms zu erreichen, entschieden sie sich, statt 750.000 Zeilen des WebRTC-Stacks anzufassen, den gesamten Stack von Grund auf passend zur gewünschten Hardware zu entwerfen und neu zu implementieren.
→ Für Sicherheit, Performance und Wartbarkeit fiel die Wahl auf Rust
Hauptsächlich verwendete Crates
→ Bessere Alternativen zur Standardbibliothek: crossbeam, parking_lot, bytes, socket2
→ Für hübschere Logs und CLI: fern, structopt
→ cargo-Helfer: cargo-release, cargo-udeps, cargo tree, cargo-geiger, cargo-flamegraph
Schwierige Seiten von Rust
-
Lange Compile-Zeiten
-
Unzureichende Bibliotheksabdeckung
-
Verlangt von Anfang an präzisen und klaren Code
-
Die Typinferenz ist so leistungsfähig, dass es sich manchmal anfühlt, als würde man eine dynamisch typisierte Sprache verwenden
-
Die Sprache entwickelt sich noch weiter
Das Ergebnis der Entscheidung für Rust
-
Keine softwarebedingten Ausfallzeiten erlebt
-
Durch effiziente Ressourcennutzung ließ sich leicht performanter Code schreiben
-
CPU- und Speichernutzung sind beide vorhersehbar und konsistent
-
Gewährleistet konsistente Latenz und Framerate
-
Auch die Erfahrung bei der Pflege der Codebasis war hervorragend
-
Am Ende entstand ein wartbares und zuverlässiges Produkt mit hoher Performance bei Framerate, Latenz und Ressourceneffizienz
→ Ohne Rust wäre das schwierig gewesen
Noch keine Kommentare.