Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
vidgear
A High-performance cross-platform Video Processing Python framework powerpacked with unique trailblazing features :fire:
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
I dabbled with QUIC a few years ago and I cannot agree more. It was pleasant to work with, and because it's UDP based, suddenly you can do NAT hole punching more easily.
Funny that you mentioned a VPN, because I make a little experimental project back then to hole punch between two behind-the-NAT machines and deliver traffic between them over QUIC. I was able to make my own L2 and L3 bridge across the WAN, or just port forward from one natted endpoint to an endpoint behind a different NAT.
At one point I used it to L2 bridge my company's network (10.x) to my home network (192.168.x), and I was able to ping my home server from the bridging host. It was quite fun.
Here's the project if anyone is interested: https://github.com/binwiederhier/natter -- it's probably defunct, but it was only experimental anyway.
My experience that played out over the last few weeks lead me to a similar belief, somewhat. For rather uninteresting reasons I decided I wanted to create mp4 videos of an animation programmatically, from scratch.
The first solution suggested when googling around is to just create all the frames, save them to disk, and then let ffmpeg do its thing from there. I would have just gone with that for a one-off task, but it seems like a pretty bad solution if the video is long, or high res, or both. Plus, what I really wanted was to build something more "scalable/flexible".
Maybe I didn't know the right keywords to search for, but there really didn't seem to be many options for creating frames, piping them straight to an encoder, and writing just the final video file to disk. The only one I found that seemed like it could maybe do it the way I had in mind was VidGear[1] (Python). I had figured that with the popularity of streaming, and video in general on the web, there would be so much more tooling for these sorts of things.
I ended up digging way deeper into this than I had intended, and built myself something on top of Membrane[2] (Elixir)
[1] https://abhitronix.github.io/vidgear/
Since it lives on top of UDP, I believe all you need is SOCK_DGRAM, right? The rest of QUIC can be in a userspace library ergonomically designed for your programming language e.g. https://github.com/quinn-rs/quinn - and can interoperate with others who have made different choices.
Alternately, if you need even higher performance, DPDK gives the abstractions you'd need; see e.g. https://dl.acm.org/doi/abs/10.1145/3565477.3569154 on performance characteristics.
Well it's abandoned and experimental, and there are better ways to hole punch than what I did, e.g. using STUN and TURN. But yeah it could replace one ngrok use case, though I think ngrok does not do L2/3 bridges.
Also: I think technically this was my first Go program (https://github.com/binwiederhier/re), but that was so tiny that it doesn't really count. ;-)
