Bitswap 1.2.0 #269
Bitswap 1.2.0 #269
Conversation
aschmahmann
force-pushed
the
feat/bitswap-spec-improvement
branch
4 times, most recently
from
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.
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.
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.
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.
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.
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 <[email protected]>
…fied priority. Change introduction. Fix whitespace.
aschmahmann
force-pushed
the
feat/bitswap-spec-improvement
branch
from
c9b1451
to
33e7afc
Compare
aschmahmann
force-pushed
the
feat/bitswap-spec-improvement
branch
from
1c36bd1
to
231112f
Compare
aschmahmann
force-pushed
the
feat/bitswap-spec-improvement
branch
from
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