CIP-0164 | Leios Mini-Protocols - #1227
Conversation
Describe what protocol pipelining is rather than provide a implementation design. Protocol pipelining can be implemented in number of ways, e.g. it can be single threaded, concurrent or a parallel design is possible.
| enough. To avoid unclean mini-protocol shutdown, `MsgLeiosNoBlockAnnouncement` | ||
| can be used, which gives back the agency to the client, which can decide | ||
| whether to continue the mini-protocol (e.g. further await for data | ||
| availability) or terminate the mini-protocol with `MsgDone`. The |
There was a problem hiding this comment.
The
cardano-nodeimplementation deactivation timeout is set to300s.
Based on where that sentence occurs and the fact that I'm not familiar with the phrase "The cardano-node implementation deactivation timeout", my first interpretation was that you were suggesting 300s for the idle timer to cause the server to send MsgLeiosNoBlockAnnouncement.
I just CTRL-Fed and confirmed that "deactivation" only occurs in this paragraph.
Would you elaborate what the meaning of "The cardano-node implementation deactivation timeout" is, in order for the reader to understand that side of tradeoff this paragraph is highlighting? Maybe just bring the second-to-last sentence up to before this reference to it?
There was a problem hiding this comment.
If the outbound governor decides to demote the peer, then it signals each mini-protocol and if any of them is not finished within deactivation timeout (e.g. 300s), then the connection will be closed abruptly (non-clean shutdown). This gives a different outcome for Hot -> Warm demotion, since in the non-clean demotion the peer will end up as Cold rather than Warm.
| `cardano-node` implementation deactivation timeout is set to `300s`. Note that | ||
| this timeout must still be preserved if the mini-protocol is pipelined, e.g. if | ||
| we pipeline five `MsgLeiosAnnounceRequestNext` messages, and we send | ||
| `MsgLeiosNoBlockAnnouncement` after `10s`, it will take the client exactly `50s` |
There was a problem hiding this comment.
it will take the client exactly
50sto await for all the pipelinedMsgLeiosAnnounceRequestNextreplies to arrive before it will be able to sendMsgDone
The typed-protocol EDSL forces the pipelined peer to have collected a response to all of its requests before it can terminate with the Done action.
But... what's stopping it from sending a pipelined MsgDone?
- It sends N pipelined requests.
- It receives signal to terminate.
- It can't send
MsgDonebecause the pipeline is full (max depth already reached). - As soon as one
MsgLeiosNoBlockAnnouncementarrives, it can sendMsgDone. - If the server has a LookAhead (see Add Lookahead, the dual to Pipelined IntersectMBO/typed-protocols#93), then the server can immediately react to that
MsgDoneby sending N-1MsgLeiosNoBlockAnnouncements. (IE, basically cancelling the pipelined requests.) - Then both server and client can gracefully terminate---after exactly one server-side timeout (+ ~1 RTT).
What do you think?
There was a problem hiding this comment.
What do you think?
In particular, does this disarm the tradeoff the paragraph mentions?
There was a problem hiding this comment.
Even if you pipeline MsgDone, you still need to collect all the results, including the result of sending MsgDone before you'll be able to use the Done constructor - so it's not allowed by construction.
There was a problem hiding this comment.
I don't think we can pipeline MsgDone and terminate the protocol, while the other side is still sending requested responses. We still need to receive all the data from the sending peer, so that the mini-protocol can be restarted if the peer is re-promoted: demotions / promotions can happen multiple time within lifetime of a connection.
Since we have now 4 mini-protocols, it is clearer to have 4 IER tables: one for each mini-protocol.
50f5315 to
01c915e
Compare
MsgLeiosNoBlockAnnouncement(LeiosAnnouncemini-protocol)MsgLeiosNoVotes(LeiosVotesmini-protocol)MsgLeiosBlockNoOffers(LeiosBlockNotifymini-protocol)