feat(peer-exchange): support peer retrieval by cluster/shard#628
feat(peer-exchange): support peer retrieval by cluster/shard#628
Conversation
jm-clius
left a comment
jm-clius
left a comment
There was a problem hiding this comment.
Thanks for this! I have added some comments. I'm not sure, however, if we should merge this or keep the PR open until we have more need for this feature. The current workaround seems to be sufficient, but we may need to evaluate.
|
|
||
| To allow for fast responses, responders SHOULD retrieve peers unsolicited (before receiving a query) | ||
| and maintain a queue of peers for the purpose of providing them in peer exchange responses. | ||
| and maintain a queue of peers by their `cluster_id`/`shard` for the purpose of providing them in peer exchange responses. |
There was a problem hiding this comment.
Might need to link to the RFC here where these concepts are defined.
There was a problem hiding this comment.
There is no rfc for this. Previous approve was to maintain a LRU for peers, and remove the oldest when the capacity is reached. This cache data structure should account for cluster id and shard id for easier retrieval by shard. This is the PR where i created the maintained ds for go-waku. logos-messaging/logos-delivery-go#840
Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com>
Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com>
Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com>
Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com>
Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com>
|
Continue discussion at logos-messaging/specs#6. Some Waku rfcs are being moved to waku/specs repo as there will be a new rfc process. |
3 participants
No description provided.