Commit 0c3dc47e authored by Jeromy's avatar Jeromy

update bitswap readme

parent 44ac859e
...@@ -7,18 +7,36 @@ network from other ipfs peers. ...@@ -7,18 +7,36 @@ network from other ipfs peers.
Bitswap has three main operations: Bitswap has three main operations:
###GetBlocks ###GetBlocks
`GetBlocks` is a bitswap method used to request multiple blocks that are likely to all be provided by the same peer (part of a single file, for example). `GetBlocks` is a bitswap method used to request multiple blocks that are likely
to all be provided by the same peer (part of a single file, for example).
###GetBlock ###GetBlock
`GetBlock` is a special case of `GetBlocks` that just requests a single block. `GetBlock` is a special case of `GetBlocks` that just requests a single block.
###HasBlock ###HasBlock
`HasBlock` registers a local block with bitswap. Bitswap will then send that block to any connected peers who want it (strategy allowing), and announce to the DHT that the block is being provided. `HasBlock` registers a local block with bitswap. Bitswap will then send that
block to any connected peers who want it (strategy allowing), and announce to
the DHT that the block is being provided.
##Internal Details ##Internal Details
All `GetBlock` requests are relayed into a single for-select loop via channels. Calls to `GetBlocks` will have `FindProviders` called for only the first key in the set initially, This is an optimization attempting to cut down on the number of RPCs required. After a timeout (specified by the strategies `GetRebroadcastDelay`) Bitswap will iterate through all keys still in the local wantlist, perform a find providers call for each, and sent the wantlist out to those providers. This is the fallback behaviour for cases where our initial assumption about one peer potentially having multiple blocks in a set does not hold true. All `GetBlock` requests are relayed into a single for-select loop via channels.
Calls to `GetBlocks` will have `FindProviders` called for only the first key in
When receiving messages, Bitswaps `ReceiveMessage` method is called. A bitswap message may contain the wantlist of the peer who sent the message, and an array of blocks that were on our local wantlist. Any blocks we receive in a bitswap message will be passed to `HasBlock`, and the other peers wantlist gets updated in the strategy by `bs.strategy.MessageReceived`. the set initially, This is an optimization attempting to cut down on the number
of RPCs required. After a timeout (specified by the strategies
`GetRebroadcastDelay`) Bitswap will iterate through all keys still in the local
wantlist, perform a find providers call for each, and sent the wantlist out to
those providers. This is the fallback behaviour for cases where our initial
assumption about one peer potentially having multiple blocks in a set does not
hold true.
When receiving messages, Bitswaps `ReceiveMessage` method is called. A bitswap
message may contain the wantlist of the peer who sent the message, and an array
of blocks that were on our local wantlist. Any blocks we receive in a bitswap
message will be passed to `HasBlock`, and the other peers wantlist gets updated
in the strategy by `bs.strategy.MessageReceived`.
If another peers wantlist is received, Bitswap will call its strategies
`ShouldSendBlockToPeer` method to determine whether or not the other peer will
be sent the block they are requesting (if we even have it).
##Outstanding TODOs: ##Outstanding TODOs:
- Ensure only one request active per key - Ensure only one request active per key
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment