Does anyone know if this tech (or Iroh) is suitable for real-time networking for games? Basically, once connection is established, what's the overhead on top of UDP in terms of latency and bandwidth?
Edit: after digging a little, Iroh uses QUIC which looks like a reliable, ordered protocol as opposed to the unreliable, unordered nature of UDP which is what many games need.
Now what I'd love to figure out is if there's a way to use their relay hopping and connection management but send/receive data through a dumb UDP pipe.
> QUIC which looks like a reliable, ordered protocol as opposed to the unreliable, unordered nature of UDP which is what many games need.
This isn't right, as a sibling comment mentions. QUIC is a UDP-based protocol that handles stream multiplexing and encryption, but you can send individual, unordered, unreliable datagrams over the QUIC connection, which effectively boils down to UDP with a bit of overhead for the QUIC header. The relevant method in Iroh is send_datagram: https://docs.rs/iroh-net/latest/iroh_net/endpoint/struct.Con...
It would be nice if dumbpipe revealed the local and remote IP and UDP port numbers via something like STDERR or a signal so that apps could send UDP datagrams on them with ordinary socket calls. I'm guessing that QUIC uses a unique header in its first few bytes, so the app could choose something different and not interfere with the reliable stream.
A better solution would be to expose the iroh send_datagram and read_datagram calls somehow. Maybe if dumbpipe accepted a datagram flag like -d, then a second connection to a peer could be opened. It would recognize that the peer has already been found and maybe reuse the iroh instance. Then the app could send over either stream when it needs to be reliable or best effort.
This missing datagram feature was the first thing I thought of too when I read the post, so it's disappointing that it doesn't discuss it. Mostly all proof of concept tools like this are MVP, so don't attempt to be feature-complete, which forces the user to either learn the entirety of the library just to use it, or fork it and build their own.
IMHO that's really disappointing and defeats the purpose of most software today, since developers are programmed to think that the "do one thing and do it well" unix philosophy is the only philosophy. It's a pet peeve of mine because nearly the entirety of the labor I'm forced to perform is about working around these artificial and unintentional limitations.
> It would be nice if dumbpipe revealed the local and remote IP and UDP port numbers via something like STDERR or a signal so that apps could send UDP datagrams on them with ordinary socket calls.
I believe this would be even more unreliable than UDP, since Iroh is also capable of using a relay server for when hole punching can't be performed, and Iroh also handles IP migration.
> it appears to be linux and macOS only
Iroh should work on Windows, IIUC, just the installer and possibly prebuilt binaries aren't provided. But dumbpipe isn't designed for UDP anyways, it's closer to a competitor for socat/nc.
Take a broader view of what "building secure systems" means. It's not just about the code being written by ICs but about the business incentives, tech choices of leadership, the individual ways execs are rewarded, legacy realities, interactions with other companies, and a million other things. Our institutions are a complex result of all of these forces. Taken as a whole, and looking at the empirical evidence of companies and agencies frequently leaking data, the conclusion "we cannot build secure systems" is well founded.
This is accurate. Especially in shops that implement firm shipping dates for Product Increments. You have X weeks to build Y features consisting of Z tickets.
At the end of those X weeks you better have all your tickets done. So more often than not, the tickets are done and the features are implemented. Shops like this build incredible ticket closing machines. They are implemented to pass user acceptance testing not to hold back hackers or bad actors. When leadership incentivizes delivering features and a developers job or raise depends on delivering those features, you get what you incentivize.
Everyone's talking about the music but I also love the dot rendering system you're using for terrain and plants! Very neat effect, simple but it's a nice style. I'd love to see a whole forest done like this, maybe a flowing river too.
Steve put the nail in the coffin but the downfall started and was primarily caused by Macromedia being purchased by Adobe, IMHO. All the problems of Flash were solvable had it continued to been driven by a team and leadership that understood and cared about product quality. IMO this is one of the clearest cases of tech acquisition making the world worse.
This is missing much, including that we've outsourced our manufacturing (and thus CO2 from manufacturing) but we still buy lots of stuff that requires intense manufacturing.
I've made https://sprig.land, a webgpu-based game engine and have plans to transpile the whole thing into a new visual scripting language I'm inventing but I'll eventually share it and do want to make games with it.
Note that when the parent comment says "software rendering" they're referring to software (compute shaders) on the GPU.