Skip to content
This repository has been archived by the owner on Jul 21, 2023. It is now read-only.

Is there a way to attempt to retry / reconnect in case of a disconnect? #117

Closed
ikreymer opened this issue Dec 19, 2020 · 2 comments
Closed

Comments

@ikreymer
Copy link

Perhaps related to #77, but I couldn't find if there's anything that handles a WebSocket onerror or onclose event
(maybe that is in it-ws ?) that would attempt to reestablish a connection.

I think manifestation of this is that if the WebSocket connection to a preload node in js-ipfs is disconnected, there doesn't seem to be any attempt to reconnect via ws?

It would be great if there was some sort of retry mechanism to establish a previously valid connection WS connection..

I thought the issue could be in this library, but not 100% sure, or maybe I'm missing something as well.. (Feel free to close if this is not applicable).

@vasco-santos
Copy link
Member

Hey @ikreymer

Thanks for reaching out.
There is no way at the moment, but we will be working on that soon. As a temporary solution, you have two possibilities for reconnect:

  • Ping peers you care about over time to avoid connection timeout
  • Listen for libp2p.connectionManager.on('peer:connect', (connection) => {}) and if it includes a peer you care about, trigger a dial

I think manifestation of this is that if the WebSocket connection to a preload node in js-ipfs is disconnected, there doesn't seem to be any attempt to reconnect via ws?

Yes, that is true at the moment. Not only for websockets but also for the other transports.
There are different flows in this case that need to be considered, as you mentioned: retry or reconnect on connection timeout.

Regarding the reconnect on connection timeout, this will be part of the Connection Manager overhaul, more specifically the Keep Alive milestone. This will also probably be combined with tags, such as a protected tag that marks a connection as important to be kept over time. With this in mind, this should be part of libp2p itself and not in the transport layer.

In the retry side of things, we should probably consider this for the Connection Manager overhaul as well. However, this will probably be transport layer. Perhaps a transport configuration.

I am going to add this the Connection Manager overhaul issue for tracking. The plan will be to ship some of those milestones with [email protected]. An issue to track that release will be created in the js-libp2p repo soon.

@vasco-santos
Copy link
Member

Closing this as this will be handled in the connection manager overhaul. Fell free to re-open if you have any further questions

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants