[HN Gopher] Snap: A microkernel approach to host networking (2019) ___________________________________________________________________ Snap: A microkernel approach to host networking (2019) Author : teleforce Score : 68 points Date : 2021-08-21 14:03 UTC (8 hours ago) (HTM) web link (research.google) (TXT) w3m dump (research.google) | techthumb wrote: | How does this compare to OpenOnload? | jeffbee wrote: | Hard comparison to make. Snap can be used with traditional | socket APIs, but that is not really its purpose. OpenOnload can | _only_ be used that way. | kwindla wrote: | So much interesting stuff happening in userspace networking these | days. It really feels like the pieces are almost there to treat | the network as just another part of the stack that you're | programming. (Albeit a pretty low-level part!) | | If you're interested in Google Snap, you might also want to take | a look at Snabb [0], and Rush (Snabb in Rust) [1]. | | For an example of how this stuff is useful at sub-Google scale, | we just open-sourced the Rush-based tools we use to test our | WebRTC code [2] | | [0] https://blogs.igalia.com/dpino/2017/11/13/snabb-network- | tool... | | [1] https://github.com/eugeneia/rush | | [2] https://github.com/daily-co/synthetic-network | dochtman wrote: | Rush sounds interesting, but the README is pretty sparse. Do | you know more context/background? | kwindla wrote: | Sure. We [0] make APIs for live video and audio, so we do a | lot of different kinds of network testing. Over time, we had | cobbled together a variety of tools to support load/scaling | testing, CI/CD, testing during development, and helping our | customers debug and test their applications. For all of | these, some ability to simulate packet loss, latency, jitter, | and other network realities is somewhere between helpful and | critical. | | I'm a big fan of Snabb, and had a few conversations with Max | Rottenkolber, one of the Snabb authors, about how we might | tackle building a common network-simulation framework that we | could use across all the different kinds of testing we do. | Max suggested more or less the approach that you can see in | the synthetic-network repo. (He wrote a series of documents | during implementation that are really fun reading. They are | in the /doc directory.) | | Since we increasingly use Rust in various places, and our use | case was a bit different than the core use cases for Snabb, | Max took a swing at porting parts of Snabb to Rust for the | synthetic-network project. That worked out really well, and | that Snabb-implemented-in-Rust is now Rush! | | [0] https://www.daily.co/ | masklinn wrote: | > So much interesting stuff happening in userspace networking | these days. It really feels like the pieces are almost there to | treat the network as just another part of the stack that you're | programming. (Albeit a pretty low-level part!) | | There's also fly doing userland tcp over userland wireguard | because peeps might not have a local wireguard client. | dochtman wrote: | It's not just Fly IIRC, the official macOS Wireguard also | relies on userland Wireguard (wireguard-go), as does | Tailscale. | kwindla wrote: | > There's also fly doing userland tcp over userland wireguard | because peeps might not have a local wireguard client. | | Oh, yeah! That whole thing [0], up through the integration | with flyctl, is fire. | | [0] https://news.ycombinator.com/item?id=26315695 ___________________________________________________________________ (page generated 2021-08-21 23:01 UTC)