gossipsub: Topic Streams Extension#729
Conversation
| When this extension is negotiated, the original gossipsub stream becomes the | ||
| control stream. Application messages (such as the `Message` or | ||
| `PartialMessagesExtension` messages) MUST NOT be published on the control | ||
| stream. |
There was a problem hiding this comment.
What do you think about a design where we have per topic control streams too?
So the control stream would share the topic relevant: IHave, IWant, IDontWant, and maybe Graft and Prune
This allows:
Easier implementation. Need to read a control scoped RPC.
Heartbeat can now be per topic and be staggered by having different topics at different times, and also more frequent for some topics.
Less HOL Blocking when sharing IHave, IWant, IDontWant
And mostly the fact that there really isn't any reason that control messages for a topic should interleave with control messages of another topic.
Similarly What do you think about?
1 topic control stream as defined above
1 topic data stream per message.
With this design we get nice cancellation properties. So we can cancel in progress sends easily. And if we add message preambles / ids before sending messages we can also reset on the receive side.
There was a problem hiding this comment.
Discussed synchronously. Resolved that theoretically 1 topic control stream would be better, the actual utility doesn't justify its implementation complexity. Decided to leave as is.
| If there are multiple streams for a single topic, the receiver SHOULD process | ||
| them in the order the streams were opened by the initiator. The receiver | ||
| SHOULD limit the number of concurrent topic streams for the same topic to 3 and | ||
| downscore peers that open more. Initiators SHOULD limit the number of | ||
| concurrent topic streams to 1 per topic. The initiator MUST close the old | ||
| stream before writing on a new stream for a given topic. |
There was a problem hiding this comment.
it's a bit confusing, why would there be 3 streams?
Is this because of subscribe, unsubscribe, subscribe, unsubscribe kind of pattern?
There was a problem hiding this comment.
right, or if the implementation opens a new stream per message. Because there is a potential for packets to be reordered or delayed, the sender should avoid concurrent streams that could appear to the receiver as multiple concurrent streams open at the same time.
2 participants
Gossipsub v1.3 uses a single stream per direction for all RPCs. This introduces some problems: unnecessary head of line blocking between messages (especially problematic when a large message in one topic delays small messages in another topic) and topic name overhead on each message.
The Topic Streams Extension addresses these problems. It moves topic scoped application messages to separate long-lived streams.