AtHeartEngineer/specs
1
0
Fork 0
mirror of https://github.com/vacp2p/specs.git synced 2026-01-09 15:28:03 -05:00
Code Issues Packages Projects Releases Wiki Activity

Specify type for pubsub seqno for implementation interoperability

Browse Source
This commit is contained in:
Age Manning
2019-01-21 12:25:28 +11:00
parent cc406d5313
commit 9a5fe41f30
1 changed files with 9 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
pubsub/README.md
View File

@@ -76,15 +76,15 @@ done to allow content to be routed through a swarm of pubsubbing peers.
The `data` field is an opaque blob of data, it can contain any data that the
publisher wants it to.
The `seqno` field is a linearly increasing number that is unique among messages
originating from each given peer. No two messages on a pubsub topic from the
same peer should have the same `seqno` value, however messages from different
peers may have the same sequence number, so this number alone cannot be used to
address messages. (Notably the 'timecache' in use by the floodsub
implementation contains a `message_id`, which is constructed from the
concatenation of the `seqno` and the `from` fields. This `message_id` is then
unique among messages. It was also proposed in
[#116](https://github.com/libp2p/specs/issues/116) to use a `message_hash`,
The `seqno` field is a 64-bit big-endian uint that is a linearly increasing
number that is unique among messages originating from each given peer. No two
messages on a pubsub topic from the same peer should have the same `seqno`
value, however messages from different peers may have the same sequence number,
so this number alone cannot be used to address messages. (Notably the
'timecache' in use by the floodsub implementation contains a `message_id`,
which is constructed from the concatenation of the `seqno` and the `from`
fields. This `message_id` is then unique among messages. It was also proposed
in [#116](https://github.com/libp2p/specs/issues/116) to use a `message_hash`,
however, it was noted: "a potential caveat with using hashes instead of seqnos:
the peer won't be able to send identical messages (e.g. keepalives) within the
timecache interval, as they will get rejected as duplicates."