Reconnect after disconnect/timeout

[blinry]

Hey Iroh peeps! <3

For Ethersync, we'd like to be able to say: "Here's your peer's Node ID, please connect to it and stay connected unless we tell you otherwise!" For example, when we want to keep a laptop connected to a smartphone, but the laptop is occasionally turned off, it would be neat to have Iroh attempt occasional reconnects, maybe with exponential backoff.

1. Is there something Iroh can do to help us with that, or is it something you expect the users of the library to implement themselves?
2. Have you ever seen something like this implemented somewhere (with Iroh), where we could take inspiration from?
3. Would setting the max_idle_timeout to None achieve what we want? 🤔 [Narrator voice: "But at what cost?!"]

[matheus23]

Is there something Iroh can do to help us with that, or is it something you expect the users of the library to implement themselves?

I think this is something that can/should be built entirely on top of iroh :)

Have you ever seen something like this implemented somewhere (with Iroh), where we could take inspiration from?

... Kind of. First I'd like to say that I think there's a lot of related concerns with applications where you essentially want to "keep one connection open while both ends are alive":

• You want to try re-connecting after network failure
• You want to close duplicate connections (e.g. if both ends dial each other simultaneously, then one connection should be closed)
• You want to throw away old connections that have not yet timed out, if a new connection comes in.

Some of these problems were solved independently, but I'm still collecting all the requirements and ideas for how to fix all of these (and also find the time) to build a general "ConnectionManager" thing.

As for existing code, there's

• the reconnect behavior of quic-rpc
• the connection deduplication behavior of iroh-gossip
• and there's some connection manager experiments that Michael and I collaborated on

I do think doing the deduplication right & re-connection behavior are both related concerns. You need them every time you care about keeping connections open.

I've also heard some folks would be interested in kind of the opposite: Auto-closing connections once it's been idle for long enough, and then having fast re-connects using QUIC's 0-RTT. But maybe that goes too far for now.

Would setting the max_idle_timeout to None achieve what we want? 🤔 [Narrator voice: "But at what cost?!"]

Good question. I don't think QUIC is meant to do exponential backoff when it retransmits. So yeah I think you'd constantly be sending probes around (not a lot of data, probably, but still wasteful).

[blinry]

Thanks for the detailed response, that helps us a lot understanding the involved problem better! 😊

We'll start with our own "connection manager". It'd be great if you ever decided to include some of the functionality you talked about!

[flub]

3. Would setting the max_idle_timeout to None achieve what we want? 🤔 [Narrator voice: "But at what cost?!"]

My understanding is that on the QUIC this should work, but it's rather sketchy territory that you should explore. QUIC closes the connection either when:

• idle timeout (which you're disabling here)
• immediate close, which neither side would be sending
• stateless reset, feel free to ignore this, won't happen in this case

But I'm not entirely sure if iroh internals will deal with this gracefully. I think it is reasonable to ask us to support this.

[flub]

For the "exponential backofff" part of leaving this to QUIC: a packet would be sent and would not be acked. After some delay derived from the RTT more packets would be attempted to be sent. I think this would more or less keep repeating until it is re-established. So essentially the alive side will keep sending something every few seconds.

This is "reasonable" since it's just considering this as packet loss, not as disconnected. Only once a newer packet gets acknowledged will all the previous packets be declared lost and their contents will be re-sent as needed at this time.