Peer Management: Automated actions upon reconnection

[fryorcraken]

Planned start date:
Due date:

Summary

In the context of using req/resp protocols, especially filter, a disconnection/reconnection to a remote peer may mean a lost to internet connection, which may lead to:

• missing incoming messages (remote filter node was not able to push messages)
• failed to send messages (remote light push node was unavailable during the connection loss)

Taking an holistic view, js-waku should provide handy API/plugins to enable an app to restore services and repair from temporary loss of connectivity.

Acceptance Criteria

• Filter subscriptions are restored upon reconnection
• Filter PING is regularly used to confirm subscription are still active, if error is detected, it should trigger a subscription restoration attempt.
• API is available to indicate when sending via light push is available, especially after sending failure
• Store query is automatically done using last received message after it is detected that a disconnection or subscription loss happened.

Tasks

RAID (Risks, Assumptions, Issues and Dependencies)

• Dependency on feat: SDK for redundant usage of filter/lightpush #1463 in terms of dupe message handling
• • Dependency on feat: SDK for redundant usage of filter/lightpush #1463 in terms of selecting best remote peer to restore services with
• Dependency on Peer Management: Connection and Disconnection #914 in terms of automated reconnection

• Unsure if this should be core functionality or a plug-in as automated store query may be a heavy operation.
  • For example. if light push sent to fail a message, then it may be application logic to re-attempt sending but js-waku needs to provide API to make it clear when it is ready to send again.
  • Steps are likely to implement most of the logic in separate plug-in or application and then review what needs to be integrated in core logic.
• Risk of overloading remote nodes when automated actions are done upon network unstability (e.g. connection loss may be due to remote node overloaded), need to be sure back-off strategies are used when relevant and possibly rotating between use remote nodes.