Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Epic: js-waku] Reliability Protocol for Resource-Restricted Clients #2154

Closed
27 of 39 tasks
Tracked by #186
chair28980 opened this issue Feb 26, 2024 · 13 comments
Closed
27 of 39 tasks
Tracked by #186
Assignees
Labels
E:js-waku Reliability Protocol for Resource-Restri epic Tracks a yearly team epic (only for waku-org/pm repo)

Comments

@chair28980
Copy link
Contributor

chair28980 commented Feb 26, 2024

Our user story:

  1. As a developer, I want a simple API to register hooks to process messages on one or several content topics: feat(filter)!: new simpler filter API  #2092
  2. As a developer, I do not care about shards or pubsub topics, I am only using autosharding
  3. As developer, I want fair reliability when receiving messages (e..g redundant filter nodes + filter ping + store sync)
  4. As a developer, I do not want the same incoming message to be processed several times (e.g. filter redundancy should be abstracted)
  5. As a developer, I want fair reliability when sending messages.

And our implementation notes:

Store

Combination

Liveness of a node:

Testing

Filter:

LightPush:


First revision

Tasks (obsolete)

We can de-scope some of these streams in the interest of time.

Second revision

Filter:

LightPush:

  • ensure number of peers to use is
    • configurable
    • documented

Store

Liveness of a node:

Testing

@chair28980
Copy link
Contributor Author

@waku-org/js-waku-developers please proceed with creating the tasks required in the js-waku repository, please tag them with the E:js-waku Improve Reliability label, and include them in Task list above in the description.

@fryorcraken
Copy link
Collaborator

@waku-org/js-waku-developers please note that we now expect an RFC out of this work. Also, need to understand what is done in status-go and align. @chaitanyaprem would be a good person to discuss with as he has some familiarity with usage of req-res protocols in status-go

@weboko
Copy link
Collaborator

weboko commented Apr 26, 2024

in status-go

I was planning to schedule knowledge sharing after Status offsite is done

we now expect an RFC out of this work

after knowledge sharing and revisiting completed work we will discuss RFC internally

@fryorcraken
Copy link
Collaborator

is there an understanding of what of the change listed above would give you most ROI?

@danisharora099
Copy link
Collaborator

danisharora099 commented May 31, 2024

is there an understanding of what of the change listed above would give you most ROI?

A lot of high-impact items have been merged, or are in progress. Other than that, imo:

  • all protocols: disconnection management (P1)

  • filter: validating filter messages from each node against each other to do disconnection (P3)

  • filter: running recurring store queries to validate incoming filter messages (dependant on store v3) (P2)

  • filter: pinging per peer, instead of per subscription (P3)

  • lightpush: seems quite stable once disconnection management is implemented

  • store: store v3

  • client/node stability:

    • ensure peers are redialed (if not dialed already)
    • recover filter subscriptions
    • running store query upon reconnection to receive missed filter messages

@chair28980 chair28980 changed the title [Epic: js-waku] Composing Waku Protocols to Improve Reliability [Epic: js-waku] Reliability Protocol for Resource-Restricted Clients Jun 4, 2024
@danisharora099
Copy link
Collaborator

danisharora099 commented Jun 28, 2024

status-im/status-go#5344

Based on status-im/status-go#5350 and status-im/status-go#5344 (comment). it seems that status-go did not filter peers based on shards when discovered using Peer Exchange, thus attempting to open subscriptions with peers with unsupported pubsub topics.

waku-org/go-waku#1124

Investigating this: waku-org/go-waku#1124 (comment)

waku-org/go-waku#1128

Very interesting. Though we haven't run into a problem like this before (perhaps because of the nature of js-waku node being short lived, thus peer updating its addresses was never observed) -- but this seems to be a very important check to introduce. Opened an issue here: #2051

@chaitanyaprem
Copy link

This is the master issue i am using to track all fixes/changes wrt lightclient reliability being done in go-waku/status-go. waku-org/pm#219
@danisharora099 , @weboko you can refer to this to see if something that can be applied to js-waku and also can be added to the rfc.

@weboko
Copy link
Collaborator

weboko commented Jul 2, 2024

Another point to consider from @jm-clius comment here - waku-org/specs#18 (review):

  • verify delivered messages by tracking them by Filter subscription to some node that is different from the one used during LightPush.

Let's discuss at js-waku PM meeting, @danisharora099

@danisharora099
Copy link
Collaborator

danisharora099 commented Jul 17, 2024

Strictly based on the newly merged Reliability RFC, derived features and their current state in the js-waku codebase are:

Node Health Management

Peers and Connection Management

LightPush Protocol Enhancements

Filter Protocol Enhancements

@weboko
Copy link
Collaborator

weboko commented Jul 17, 2024

Nice, good job at summarizing!
Let's discuss it at our PM meeting tomorrow as I believe some of the features we might want to make optional such as Store / Filter message verification and retry.

Also to note: we are waiting for update to Light Push to implement some of the strategies in the RFC such as renewing peers only in some cases and doing retries in others.

Upd#1: additional task #2074
Upd#2: one more #2076

@danisharora099
Copy link
Collaborator

This epic's deliverables are now all merged in, and can be closed! (minus the unit tests issues)
cc @weboko @chair28980

@weboko
Copy link
Collaborator

weboko commented Sep 17, 2024

Unit testing is decoupled into debt and will be addressed independently.
Other things are described in waku-org/pm#186 (comment) and will be a fast follow up in dogfooding work stream.

@weboko weboko closed this as completed Sep 17, 2024
@chair28980 chair28980 transferred this issue from waku-org/pm Oct 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E:js-waku Reliability Protocol for Resource-Restri epic Tracks a yearly team epic (only for waku-org/pm repo)
Projects
Status: Done
Development

No branches or pull requests

5 participants