TCP-based transport?

[geph-official]

TCP-based transport?

[nullchinchilla]

One hack could just be KCP-X over TCP over ScrambleSuit. That way roaming isn't such a biggie. The usual pitfalls of TCP over TCP don't exactly apply since we use link modeling rather than loss-based cwnd control, and (bbr/vegas-based) TCP isn't so different from something like LTE in that respect. We could turn off all fast and early retransmits as an optimization (RTO retransmits are highly suppressed in KCP-X anyway) and use multiple TCP connections that open and close often. This should prevent us from triggering "long persistent connection" heuristics.

A better approach might be to do a proper multipath-TCP type protocol, where the onion routing is actually on unordered packets rather than streams, and KCP-X is end-to-end. That way, TCP and UDP bridges would just be "physical links" and complex ad-hoc logic wouldn't be needed. That might be very complex though, and is definitely a "geph3" type project.

[nullchinchilla]

One thing we could do is actually introduce "TCP primacy", and have clients connect over ScrambleSuit to negotiate KCP-X sessions on other ports both over TCP and UDP. This might have fingerprinting implications, but it'll also simplify the really brittle N4 handshake logic that's the source of countless bugs.

A more backwards-compatible approach might actually be N4/KCP-X primacy, but that does require more long-term maintenance of the crappy N4 handshake and crypto code. In any case the "subsidiary" streams would have really simple crypto since no handshakes are needed anymore.

[NoneSloth]

I have not read the code yet, but if all geph need is an unreliable datagram, can we use raw socket with fake TCP headers?

In that way, we have all benefits of UDP (roaming, better latency with TCP-over-UDP), and at the same time, we can make the router thinks that we are sending TCP segments.

Not an expert, just wondering if this is doable.

[nullchinchilla]

Custom/fake TCP is bad since it's a fingerprint that can be used to identify and block Geph.

[nullchinchilla]

A TCP-first approach has been pushed in e4639b2. In a future version of gephgui, clients will always first connect via TCP to bridges and then negotiate the next protocol.