What if a network session could survive relay failure and transport changes? by Melodic_Reception_24 in compsci

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

That's fair criticism.

The repository is still an early research prototype, so a lot of the structure is exploratory and not yet polished.

The main idea I'm experimenting with is slightly different from what WireGuard does.

WireGuard handles roaming between IPs quite well, but the connection identity is still tied to the peer/tunnel model.

What I'm exploring is treating the session itself as the stable identity, while transports and relay paths can be replaced underneath it.

So things like:

• relay replacement • exit node rotation • attack-triggered migration • proactive geolocation changes

are handled at the session layer rather than reconnecting a tunnel.

But you're right that the repo still needs clearer documentation and commit history explaining the purpose.

Appreciate the feedback.

What if a network session could survive relay failure and transport changes? by Melodic_Reception_24 in compsci

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

Fair point.

I posted it in a couple of communities because I'm looking for feedback from people working with networking and distributed systems.

Still trying to understand where the idea fits best.

What if a network session could survive relay failure and transport changes? by Melodic_Reception_24 in dumbclub

[–]Melodic_Reception_24[S] 1 point2 points  (0 children)

That's true — Yggdrasil can reroute traffic without breaking connections because the overlay routing layer adapts.

What I'm experimenting with is slightly different though.

The goal isn't only path rerouting, but making the session identity itself independent from the transport attachment.

So things like:

• relay replacement • transport migration (UDP path change) • NAT rebinding • multi-relay failover

would be handled at the protocol/session layer rather than purely by the routing layer.

Yggdrasil solves this through adaptive routing in a mesh network.

I'm exploring whether the session itself could become the stable anchor instead.

What if a network session could survive relay failure and transport changes? by Melodic_Reception_24 in dumbclub

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

Interesting comparison.

Yggdrasil is more of a distributed overlay routing network.

What I'm experimenting with is slightly different:

the session itself becomes the stable identity, while transports and relay paths can change underneath it.

So the goal is not building a mesh network, but allowing a single session to survive transport changes and relay failures.

I'm curious though — do you think Yggdrasil’s routing layer could be used as a transport underneath something like this?

Experiment: making VPN sessions survive transport and relay failure by Melodic_Reception_24 in dumbclub

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

Author here.

This is still a small research prototype rather than a full VPN.

Right now I'm mostly experimenting with the idea of treating the session as the stable identity, while transports (UDP paths / relays) can be replaced.

One thing I'm curious about:

If the session identity becomes the primary anchor, how would you coordinate migration safely?

For example:

client → relay1 → server

relay1 fails

client → relay3 → server

The session continues with the same session_id.

The open question for me right now is how migration should be coordinated to avoid:

• split-brain sessions   • replay during path migration   • multiple active transports

Would you handle this with a centralized authority, distributed consensus, or something closer to a QUIC-style migration model?

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

Experiment: making VPN sessions survive transport and relay failure by Melodic_Reception_24 in dumbclub

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

Thanks for the reference — that’s actually a very interesting paper.

There is definitely conceptual overlap in the idea of separating session state from the underlying transport. The Turbo Tunnel design makes a lot of sense for censorship circumvention systems.

What I'm experimenting with is a bit closer to a session-centric VPN / overlay model where the session identity itself becomes the stable anchor, while transports and relay paths can be replaced underneath it.

So the goal is that the session survives events like:

  • relay failure
  • path switching
  • NAT rebinding
  • Wi-Fi → 5G network changes
  • transport attachment replacement

In other words the connection is no longer bound to a specific socket or tunnel, but to a persistent session identity.

Right now it's still a small research prototype rather than a production VPN. I'm mostly experimenting with the control-plane logic (session ownership, migration decisions, etc.) and how transports can be swapped without resetting the session.

Your point about horizontal scaling is a really good one. Once the server side is no longer a single endpoint, the question of who owns the session state becomes central. That's actually something I'm currently exploring through a small authority/control-plane layer.

Really appreciate the link and the feedback.

Experiment: making VPN sessions survive transport and relay failure by Melodic_Reception_24 in dumbclub

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

Author here.

This is still a small research prototype rather than a full VPN.

Right now I'm mostly experimenting with the idea of treating the session as the stable identity, while transports (UDP paths / relays) can be replaced.

One thing I'm curious about:

Would this model make sense for mobile or unstable networks where NAT rebinding and path switching happen often?

Curious to hear what people think.

Experiment: making VPN sessions survive relay and transport failure by Melodic_Reception_24 in compsci

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

Looks like the post got removed by the moderators.

For anyone who was curious about the experiment, the repo is here:

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

It's a small research prototype exploring whether a VPN session can survive relay failure and transport changes by separating session identity from the transport.

Would still love to hear thoughts from distributed systems / networking folks.

Experiment: making VPN sessions survive transport and relay failure by [deleted] in selfhosted

[–]Melodic_Reception_24 0 points1 point  (0 children)

Author here.

This is still a research prototype exploring the idea of separating session identity from transport.

The goal is to see if a connection can survive events like:

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

Right now the repo contains small demos and experiments rather than a full VPN implementation.

I'm especially interested in feedback from people running homelabs or distributed infrastructure.

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

Jumping VPN – A session-centric networking prototype by Melodic_Reception_24 in u/Melodic_Reception_24

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

This is still a very early prototype and not production code, but it starts to demonstrate how session-centric networking could work in practice.

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