-
Notifications
You must be signed in to change notification settings - Fork 232
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
Bitswap 1.2.0 #269
Bitswap 1.2.0 #269
Conversation
5c7acf9
to
235ff8e
Compare
|
||
There are two primary flows that Bitswap manages: requesting blocks from and serving blocks to peers. Block requests are primarily mediated by the want-manager, which tells our peers whenever we want a new block. Serving blocks is primarily handled by the decision engine, which decides how resources should be allocated among our peers. | ||
- `/ipfs/bitswap/1.0.0` - Initial version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've also seen /ipfs/bitswap
and /bitswap/1.0.0
around digging through the GitHub history. I'm not sure if these are the same as /ipfs/bitswap/1.0.0
or different earlier versions.
Perhaps someone with sufficient history can clarify, or I can do more GitHub archaeology to learn more.
|
||
Sender: | ||
Wantlist wantlist = 1; | ||
repeated Block payload = 3; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While it appears to be supported in go-bitswap I removed repeated bytes blocks = 2;
from versions of the protocol >1.0.0 as that field is deprecated and superseded by another field (i.e. payload
). Given that we use libp2p and multistream to negotiate protocol versions there seems to be no reason why a /ipfs/bitswap/1.1.0
node should ever receive a message with the blocks
field since a node needing the blocks
field should have negotiated for /ipfs/bitswap/1.0.0
.
However, given that this behavior is likely implemented across the various implementations today I'm happy to put it back in the spec if people think it should be there.
bool full = 2; // whether this is the full wantlist. default to false | ||
} | ||
message Block { | ||
bytes prefix = 1; // CID prefix (all of the CID components except for the digest of the multihash) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The previous comment here seemed to indicate that this had to be a CIDv1 when it could be a CIDv0 as well.
**Author(s)**: | ||
- Adin Schmahmann |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just guessed this was alphabetical order by first name 🤷.
- David Dias | ||
- Jeromy Johnson | ||
- Juan Benet | ||
|
||
**Maintainers(s)**: | ||
**Maintainer(s)**: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what this is supposed to be used for/if it really makes sense to keep around. Perhaps this is an interest group that I should be adding more people in the IPFS community who are interested in the Bitswap specs and improving them or being particularly involved in protocol upgrade proposals.
Bitswap spec is being updated to clarify the 2MiB limit: ipfs/specs#269 go-ipfs chunker accepts a max size of 1MiB but protobuf wrapping can make it a bit bigger. Switching to 2MiB allows us to support blocks created using that max chunker size.
Bitswap spec is being updated to clarify the 2MiB limit: ipfs/specs#269 go-ipfs chunker accepts a max size of 1MiB but protobuf wrapping can make it a bit bigger. Switching to 2MiB allows us to support blocks created using that max chunker size. refs web3-storage/web3.storage#1269
@aschmahmann : can we merge this? This seems like a quick thing to close out before you head out. |
@BigLep yep, will get this cleaned up and ready for merge today |
… the existing versions of the bitswap protocol
Co-authored-by: Gus Eggert <gus@gus.dev>
…fied priority. Change introduction. Fix whitespace.
c9b1451
to
33e7afc
Compare
1c36bd1
to
231112f
Compare
231112f
to
906da55
Compare
The current Bitswap spec is a bit unwieldly and out of date and generally seemed in need of some cleaning up. The spec here was a rewrite but some notable changes include:
/ipfs/bitswap/1.2.0