update bitswap readme
Jeromy committed
Dec 3, 2014 at 23:48 UTC
f054be9e1fa5befaf9251e5e0996731aa845b064
1 file changed
+23
-5
exchange/bitswap/README.md
+23
-5
@@ -7,18 +7,36 @@ network from other ipfs peers.
7
Bitswap has three main operations:
8
9
###GetBlocks
10
-`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).
10
+`GetBlocks` is a bitswap method used to request multiple blocks that are likely
11
+to all be provided by the same peer (part of a single file, for example).
12
13
###GetBlock
14
`GetBlock` is a special case of `GetBlocks` that just requests a single block.
15
16
###HasBlock
16
-`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.
17
+`HasBlock` registers a local block with bitswap. Bitswap will then send that
18
+block to any connected peers who want it (strategy allowing), and announce to
19
+the DHT that the block is being provided.
20
21
##Internal Details
19
-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.
20
-
21
-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`.
22
+All `GetBlock` requests are relayed into a single for-select loop via channels.
23
+Calls to `GetBlocks` will have `FindProviders` called for only the first key in
24
+the set initially, This is an optimization attempting to cut down on the number
25
+of RPCs required. After a timeout (specified by the strategies
26
+`GetRebroadcastDelay`) Bitswap will iterate through all keys still in the local
27
+wantlist, perform a find providers call for each, and sent the wantlist out to
28
+those providers. This is the fallback behaviour for cases where our initial
29
+assumption about one peer potentially having multiple blocks in a set does not
30
+hold true.
31
+
32
+When receiving messages, Bitswaps `ReceiveMessage` method is called. A bitswap
33
+message may contain the wantlist of the peer who sent the message, and an array
34
+of blocks that were on our local wantlist. Any blocks we receive in a bitswap
35
+message will be passed to `HasBlock`, and the other peers wantlist gets updated
36
+in the strategy by `bs.strategy.MessageReceived`.
37
+If another peers wantlist is received, Bitswap will call its strategies
38
+`ShouldSendBlockToPeer` method to determine whether or not the other peer will
39
+be sent the block they are requesting (if we even have it).
40
41
##Outstanding TODOs:
42
- Ensure only one request active per key