JumpingVPN2027

This is an interesting direction.

Pushing events into an already running session feels like a step toward decoupling execution from transport state.

I've been thinking along similar lines — where a session continues to exist independently, and transports are just interchangeable carriers attached to it.

UDP always felt like a better foundation for experimentation exactly because it doesn't enforce connection semantics.

You get to define your own model of continuity on top.

I wonder if more systems should move toward explicitly modeling session continuity instead of inheriting it implicitly from transport.

It’s interesting how much of networking behavior still assumes a relatively stable path.

In practice, especially on mobile networks, path instability is the norm rather than the exception.

Feels like a lot of system design still treats failure as exceptional, while it might make more sense to treat it as a normal runtime condition.

One thing I find interesting with QUIC and similar approaches is that they still bind connection continuity quite tightly to transport state.

I've been thinking about whether session identity could be separated entirely from transport, so that transport failure becomes a recoverable event rather than connection death.

Curious if anyone has seen practical systems that push this further than QUIC does.

For people who want to quickly see the idea without reading the whole repo:

You can run a small failover demo (requires Go installed):

go run ./cmd/failover_demo

It simulates a relay failure and shows the session migrating to a new path while keeping the same session ID.

If anyone here works on networking protocols or distributed systems, I would be very interested in feedback on the architecture.

In particular:

• session identity design • relay coordination • migration safety • possible attack surfaces

This started as a personal research experiment and I'm curious how people from the networking community view the idea.

One question I'm exploring:

If session identity becomes the primary anchor of the connection, should transports even be visible to the protocol layer?

Or should transports simply become replaceable attachments that the runtime can swap without affecting the session state?

Curious how people working on QUIC / VPN protocols think about that.

This started as a small experiment while exploring how session identity could be separated from transport stability.

The current repo is just a research prototype, but the goal is to explore things like: - transport migration - relay switching - session continuity under network volatility

Happy to hear criticism or ideas from people who have worked on VPN protocols or transport layers.

Hi HN,

I'm experimenting with a session-centric networking model for VPNs.

Traditional VPNs bind connection identity to a tunnel. If the transport path fails, the connection usually resets.

In this prototype the session identity becomes the stable anchor, while transports and relay paths can change underneath.

Quick demo scenario:

SESSION CREATED client → relay1 → server

possible DDoS / path degradation detected

RELAY SWITCH

client → relay2 → server

SESSION SURVIVES

Screenshot of the demo: https://limewire.com/d/78j1c#8iNiseGB4j

I also built a small OpenVPN compatibility gateway prototype that accepts UDP traffic and maps incoming packets to a session.

Repo: https://github.com/Endless33/jumping-vpn-preview

Curious what networking / Go / distributed systems people think about a session-centric model vs tunnel-centric VPNs.

Another small detail: the prototype emits structured trace logs for every session event.

This makes it possible to verify protocol invariants and replay execution traces to debug recovery behavior.

Small clarification about the demos.

The goal of the prototype is not to build “another VPN”, but to experiment with a different connection model where the session identity is the stable anchor and transports are replaceable.

In the demos the session survives events like:

• transport failure • relay change • path replacement • NAT rebinding

The runtime treats these events as state transitions rather than connection resets.

Current prototype includes:

• session runtime with deterministic state machine • transport abstraction layer • relay forwarding experiments • trace-based invariant verification

Right now everything is still very experimental.

The main question I'm exploring is whether a session-centric model could simplify recovery logic under network volatility compared to tunnel-centric designs.

Hi HN,

Building a VPN where session is the stable anchor, transport is volatile/replaceable.

Pushed new 60-second demos: - Multipath failover (one path dies → seamless switch) - Path kill & recover - Distributed ownership takeover - NAT rebinding test

Also: basic UDP echo server runs in Termux on Android phone.

Repo: https://github.com/Endless33/jumping-vpn-preview

Short video (UDP test): https://vm.tiktok.com/ZNRuY8uug/

Looking for feedback on: - session vs tunnel-centric approach - invariants / state machine - next: QUIC + real multipath

What do networking / Go people think?

Interesting approach.

Out of curiosity — how do you maintain a stable session identity if the underlying transport path changes (for example NAT rebinding or relay migration)?

Is it tied to a cryptographic token or internal session state?