doc: some comments about the future of the decision engine
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
Brian Tiger Chow committed
Dec 17, 2014 at 03:11 UTC
bd3ee739b92d9a3740ee81e2a4eaad9eb22fafa8
1 file changed
+40
-4
exchange/bitswap/decision/engine.go
+40
-4
@@ -11,6 +11,36 @@ import (
11
u "github.com/jbenet/go-ipfs/util"
12
)
13
14
+// TODO consider taking responsibility for other types of requests. For
15
+// example, there could be a |cancelQueue| for all of the cancellation
16
+// messages that need to go out. There could also be a |wantlistQueue| for
17
+// the local peer's wantlists. Alternatively, these could all be bundled
18
+// into a single, intelligent global queue that efficiently
19
+// batches/combines and takes all of these into consideration.
20
+//
21
+// Right now, messages go onto the network for four reasons:
22
+// 1. an initial `sendwantlist` message to a provider of the first key in a request
23
+// 2. a periodic full sweep of `sendwantlist` messages to all providers
24
+// 3. upon receipt of blocks, a `cancel` message to all peers
25
+// 4. draining the priority queue of `blockrequests` from peers
26
+//
27
+// Presently, only `blockrequests` are handled by the decision engine.
28
+// However, there is an opportunity to give it more responsibility! If the
29
+// decision engine is given responsibility for all of the others, it can
30
+// intelligently decide how to combine requests efficiently.
31
+//
32
+// Some examples of what would be possible:
33
+//
34
+// * when sending out the wantlists, include `cancel` requests
35
+// * when handling `blockrequests`, include `sendwantlist` and `cancel` as appropriate
36
+// * when handling `cancel`, if we recently received a wanted block from a
37
+// peer, include a partial wantlist that contains a few other high priority
38
+// blocks
39
+//
40
+// In a sense, if we treat the decision engine as a black box, it could do
41
+// whatever it sees fit to produce desired outcomes (get wanted keys
42
+// quickly, maintain good relationships with peers, etc).
43
+
44
var log = u.Logger("engine")
45
46
const (
@@ -26,18 +56,24 @@ type Envelope struct {
56
}
57
58
type Engine struct {
29
- // FIXME peerRequestQueue isn't threadsafe nor is it protected by a mutex.
30
- // consider a way to avoid sharing the peerRequestQueue between the worker
31
- // and the receiver
59
+ // peerRequestQueue is a priority queue of requests received from peers.
60
+ // Requests are popped from the queue, packaged up, and placed in the
61
+ // outbox.
62
peerRequestQueue *taskQueue
63
64
+ // FIXME it's a bit odd for the client and the worker to both share memory
65
+ // (both modify the peerRequestQueue) and also to communicate over the
66
+ // workSignal channel. consider sending requests over the channel and
67
+ // allowing the worker to have exclusive access to the peerRequestQueue. In
68
+ // that case, no lock would be required.
69
workSignal chan struct{}
70
71
+ // outbox contains outgoing messages to peers
72
outbox chan Envelope
73
74
bs bstore.Blockstore
75
40
- lock sync.RWMutex
76
+ lock sync.RWMutex // protects the fields immediatly below
77
// ledgerMap lists Ledgers by their Partner key.
78
ledgerMap map[u.Key]*ledger
79
}