Libp2p RPC protocol and Blocksync #229
Conversation
…cksync-stable-futures
…fe/ferret into ec2/fil-blocksync-stable-futures
| /// Error code | ||
| pub status: u64, | ||
| pub message: String, |
There was a problem hiding this comment.
If commenting on each field include a comment for message for consistency.
There was a problem hiding this comment.
Just a note about this, the message isn't in the spec so it's possible it will be removed in the future, but it exists in Lotus so we are including for now
| }; | ||
|
|
||
| /// The time (in seconds) before a substream that is awaiting a response from the user times out. | ||
| pub const RESPONSE_TIMEOUT: u64 = 10; |
There was a problem hiding this comment.
I am assuming this was arbitrarily set to 10 seconds? Just trying to understand if that was for a reason or if its a standard.
There was a problem hiding this comment.
yeah it was arbitrary, can tweak it later but 10 seconds seemed like a reasonable timeout for an RPC response
|
|
||
| /// Contains the blocks and messages in a particular tipset | ||
| #[derive(Clone, Debug, PartialEq)] | ||
| pub struct TipSetBundle { |
There was a problem hiding this comment.
Slightly confused with this type...could we not utilize the pre-existing FullTipSet which has a Vec<Blocks> that contains the bls and secp messages and would describe the block each message belongs to?
Further, based on the spec and our existing implementation blocks should only contain a single header not a Vec<BlockHeader>?
There was a problem hiding this comment.
nah, this type defines specifically what is sent via the blocksync protocol. They use the tipsetbundle to remove redundant data passed over the wire.
Also what type are you saying to only include one header? for even a single tipset there should always be a vector of headers (or blocks).
Edit: what this type represents is essentially a compressed full Tipset, as in you can use the message vectors and includes arrays to put the messages in each block for the tipset
There was a problem hiding this comment.
I see that makes sense, although not completely clear how its a compressed Full Tipset as it contains the same data fields (e.g. blockheader fields and messages) and even adds an additional field with msg_includes? Could you not still use message vectors from a FullTipset?
There was a problem hiding this comment.
It's "compressed" because a tipset could have duplicate messages in the tipset in different blocks, the FullTipset is a vector of full blocks with messages, and the TipSetBundle has a dump of all headers, unique messages, and indexes for headers to messages
Summary of changes
Changes introduced in this pull request:
Reference issue to close (if applicable)
Closes
Other information and links