Thomas Eizinger
Thomas Eizinger
> > That would mean doing holepunching for TCP which requires doing a simultaneous open which is a lot more flaky then UDP hole punching. > > I meant inside...
If we open a TCP socket listening on the IP of our own TUN device, would the kernel route the traffic back to us? The could work but feels a...
> > If we open a TCP socket listening on the IP of our own TUN device, would the kernel route the traffic back to us? > > Hmm I...
We could even try to run QUIC normally and if it fails, fall back to run jt through the tunnel. Report a diagnostic event to the portal and we get...
> Let's keep this open to tackle at a later iteration. For sure! It was interesting to hash out anyway :) > First we probably need much more CI coverage...
> > First we probably need much more CI coverage (esp on the clients) to be confident in making protocol changes. > > Making it part of `snownet` by hand-crafting...
There are two ways we can run QUIC: - As separate UDP packets - Through the tunnel The main reason I'd like to use QUIC is because we need a...
> We could use the same IPC mechanism as the Tauri clients since we already have that in the repo? I'd probably use HTTP instead. Better multiplexing and running an...
> > We could use the same IPC mechanism as the Tauri clients since we already have that in the repo? > > I'd probably use HTTP instead. Better multiplexing...
The alternative is to stick to UDP and implement our own retransmits like we do for STUN messages to the relay. We are limited in packet size (I definitely don't...