Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Proposed protocol for insuring bitswap is more reliable #201

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions BITSWAP.md
Original file line number Diff line number Diff line change
Expand Up @@ -87,9 +87,18 @@ message Message {
Wantlist wantlist = 1;
optional repeated bytes blocks = 2; // used to send Blocks in bitswap 1.0.0
repeated Block payload = 3; // used to send Blocks in bitswap 1.1.0
bytes session_id = 3; // Bitswap 1.2 - id for this wantlist session
int32 frame_start = 4; // Bitswap 1.2 - start frame for deltas in a non-full message
int32 frame_end = 5; // Bitswap 1.2 - end frame for deltas in a non-full message
bytes ack_session_id = 6; // Bitswap 1.2 - acknowledge id for last received session_id
int32 ack_frame = 5; // Bitswap 1.2 - acknowledge last frame received
}
```

#### Error Correction

Bitswap 1.2 introduces session ids and frames to make the protocol more reliable. When a new peer connects, the connection is assigned a local unique session id (likely a 16 byte uuid) and a starting frame (should be >0 which is the default value for protobuf ints). Each sent want list change or block send increments the frame counter. When sending a message, one or more frames are joined together, and sent with the local session id, and the starting and ending frame. When the remote peer sends its next message (or immediately), it sends last received local session id, and the last received and transmitted frame (along with its own session_id and frame range). Deltas are never applied unless the starting frame is lesser or equal to the last frame received and applied. Skillful buffering on both sides can use this mechanism to insure an accurate wantlist is maintained and blocks are resent when neccesary. Meanwhile, the fact that the rest of the protocol is identical means the presence of default (missing) values is used to detect and downgrade when communicating with older peers.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bitswap 1.2 as in "go package version" or as in "new wire protocol"? Are these spec'ed out somewhere?


## Want-Manager

The want-manager handles requests for blocks. For a requested block, identified by `cid`, the `Bitswap.GetBlock(cid)` method is invoked. `Bitswap.GetBlock(cid)` requests `cid` from the network and, if the corresponding `Block` is received, returns it. More concretely, `Bitswap.GetBlock(cid)` adds `cid` to our wantlist. The want-manager then updates all peers with this addition by adding a new `Entry` to each peer’s message queue, who then may or may not respond with the desired block.
Expand Down