Reconnection with exponential backoff

[chr15m]

When I was building Watch Later I had to implement reconnection with an exponential backoff.

If a relay is closing a connection it should be because it doesn't want you connected to it
(@fiatjaf on #191)

I found in practical usage devices often get disconnected from relays because of moving between networks, flaky wifi, or whatever.

I also found .onClose was not a reliable indicator of websocket connectivity. It would be useful to have some kind of optional ping/heartbeat so the client can find out as soon as the websocket becomes unreliable (e.g. packets stop going through).

This is how the ws documentation addresses it:

https://github.com/websockets/ws#how-to-detect-and-close-broken-connections

[fiatjaf]

The problem is that the browser websockets API doesn't expose ping/pong, as it's supposed to be handled automatically internally and users should rely on onclose.

Or that's what I remember.

But yes, exponential backoff would be good.

[chr15m]

I didn't realize the browser handles ping/pong under the hood, thanks for the heads up. The exponential backoff seems to work well in browsers because of that.

So my main issue is on Node. To test I set up subscriptions to relays and then turn off wifi. Unlike the browser, nostr-tools never finds out those websocket connections are no longer available.

I tried manually sending pings to relays but this doesn't reliably trigger the onclose, and I additionally discovered some relays don't return the pong message.

The only reliable way I could get this to work is to have a setTimeout heartbeat that sends a dummy subscription to the relays with a timeout. If the relays never answer then it manually disconnects the websockets.

It's a bit of a mess really, and the downside is if you want a long running Node process with subscriptions to Nostr relays it is difficult. Just documenting this here in case I come back in future to fix it, or to help somebody else.

[fiatjaf]

Oh, wait.

So maybe I didn't implement ping/pong on Node.js -- of course I didn't. So that's what I should do? I never use Node.js and I think I assumed the Node.js library would do it exactly like the browser.

Ping/pong should work. Do you know what relay exactly isn't returning a pong? It might be a better idea to fix those.

[chr15m]

Yes maybe. "How do I detect and choose broken connections?" from the WS library suggests it.

The thing is:

1. even with the pings going, onclose was never thrown.
2. I thought I saw relays not responding to pings (though it works in the browser so that can't be right).

Let me do more rigorous testing and get back to you.

I guess this should be a separate issue. 🤔

[chr15m]

Ran a bunch of tests and wrote up findings on #495.

[chr15m]

I was thinking a better solution might be to just advise people to set reconnecting-websocket as the WebSocket implementation, since it's pluggable. I'll do some tests and see if it solves the issue I had.

[fiatjaf]

On https://gitworkshop.dev/fiatjaf.com/nostrlib/tree/master/pool.go (line 458) I have reconnection logic in Go that tries to keep a subscription alive as if nothing had happened. After reconnecting it sends a new REQ with an updated since filter.

The code is super confusing though, and can't be copied verbatim to JavaScript because of the goto statements, but I had something like that in mind and I think reconnecting-websocket won't work because of that.

[chr15m]

You're right, it won't work just reconnecting the websocket because of subscription logic etc.

I can port my clojurescript code over and see if that's general enough, with an option for auto updating the since field.

[chr15m]

Have implemented this in #507. A new enableReconnect flag can be true or can be a callback which receives the current subscription on reconnect and you can modify it to change e.g. the since parameter. The PR implements a backoff reconnection algorithm. There's a simple single-HTML file test in the PR comment.