logos-messaging/specs
1
0
Fork 0
mirror of https://github.com/logos-messaging/specs.git synced 2026-02-19 21:53:23 +00:00
Code Issues Packages Projects Releases Wiki Activity

remove cluster

Browse Source
This commit is contained in:
SionoiS 2025-04-10 10:19:12 -04:00
parent 484ccbb5ca
commit 85cef2cdd1
No known key found for this signature in database
GPG Key ID: C9458A8CB1852951
1 changed files with 10 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
standards/core/sync.md
View File

@ -36,8 +36,8 @@ At this point lists of message _IDs_ are sent for comparison
instead of _fingerprints_ over entire ranges of messages. instead of _fingerprints_ over entire ranges of messages.
#### Overview #### Overview
The `reconciliation` protocol operates on the following heuristic: The `reconciliation` protocol operate on the following heuristic:
1. The requestor chooses a sync range including time, cluster id, pubsub and content topics. 1. The requestor chooses a sync range including time, id, pubsub and content topics.
2. The range is encoded into a payload and sent. 2. The range is encoded into a payload and sent.
3. The requestee receives the payload and decodes it. 3. The requestee receives the payload and decodes it.
4. The range is processed and, if a difference with the local range is detected, a set of subranges are produced. 4. The range is processed and, if a difference with the local range is detected, a set of subranges are produced.
@ -122,27 +122,23 @@ All _varints_ MUST be little-endian base 128 variable length integers (LEB128) a
#### Payload encoding #### Payload encoding
The wire level payload MUST be encoded as follow. The wire level payload MUST be encoded as follow.
> Refer to [RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md#static-sharding)
RFC for cluster and shard specification.
> Please note that for each steps, bytes are concatenated. > Please note that for each steps, bytes are concatenated.
1. _Varint_ bytes of the node's cluster ID 1. _Varint_ bytes of the number of pubsub topics
2. _Varint_ bytes of the number of pubsub topics 2. For each pubsub topic, if any
3. For each pubsub topic, if any
a. _varint_ bytes of the pubsub topic length a. _varint_ bytes of the pubsub topic length
b. bytes content of the pubsub topic b. bytes content of the pubsub topic
4. _Varint_ bytes of the number of content topics 3. _Varint_ bytes of the number of content topics
5. For each content topic, if any 4. For each content topic, if any
a. _varint_ bytes of the content topic length a. _varint_ bytes of the content topic length
b. bytes content of the content topic b. bytes content of the content topic
6. For each range 5. For each range
a. _varint_ bytes of the delta encoded timestamp a. _varint_ bytes of the delta encoded timestamp
@ -187,9 +183,9 @@ The flexibility of the protocol implies that much is left to the implementers.
What will follow is NOT part of the specification. What will follow is NOT part of the specification.
This section was created to inform implementations. This section was created to inform implementations.
#### Cluster, Pubsub and Content Topics #### Pubsub and Content Topics
To prevent nodes from synchronizing messages from cluster, pubsub and content topics they don't support, To prevent nodes from synchronizing messages from pubsub and content topics they don't support,
cluster and topic information is added to each payload. topic information is added to each payload.
#### Parameters #### Parameters
Two useful parameters to add to your implementation are partitioning count and the item set threshold. Two useful parameters to add to your implementation are partitioning count and the item set threshold.