-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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 Rounds CR suggestions #2 #459
Conversation
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
@whyrusleeping each commit is an atomic change/suggestion. |
e95730a
to
21791e7
Compare
… timeout rule License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
good to const until it's required for them to be variable. TODO pass them in as configuration options
notice that moving the blockstore fetch into the manager removes the weird error handling case. License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
function should be a no-op when passed an empty slice License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
(merely by convention) License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
for clarity and to avoid errors, define a function License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
the less bitswap has to know about, the easier it'll be for readers. (This now returns Messages.) License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
we've been using maps with peers long enough now that this probably is no longer necessary License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
it seems to make sense since, in each place, the Key and Priority represent the same information b/c you know the saying... "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
Before, priority carried two pieces of information. One: priority as defined by remote peer Two: whether task is trashed This assumes the protocol is defined for natural numbers instead of integers. That may not always be the case. Better to leave that assumption outside so this package isn't coupled to the whims of the protocol. The protocol may be changed to allow any integer value to be used. Hopefully by that time, new responsibilties weren't added to the Priority variable. License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
it's only used in two places, but i think we've been using maps on IPFS types so much now that the specificity is no longer necessary License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
If we put the lock next to the fields it protects, it can sometimes make it easier to reason about threadsafety. In this case, it reveals that the task queue (not threadsafe) isn't protected by the mutex, yet shared between the worker and callers. @whyrusleeping License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
bitswap keeps the threadsafe version. observing the ledger shows that it doesn't need it anymore (ledgermanager is protected and safe). License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
this opens up the possibility of having multiple queues. And for all outgoing messages to be managed by the decision engine License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
only sort SortedEntries() License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
addresses #438 (comment) License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
addresses #438 (comment) License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
not changing this because i don't want to write a test for it now License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
in many places, entries are assigned from one slice to another and in different goroutines. In one place, entries were modified (in the queue). To avoid shared mutable state, probably best to handle entries by value. License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
09a6823
to
e6f0b17
Compare
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
@whyrusleeping may wanna have a look and make sure i didn't screw anything up here BenchmarkInstantaneousAddCat1MB-4 200 10763761 ns/op 97.42 MB/s BenchmarkInstantaneousAddCat2MB-4 panic: runtime error: invalid memory address or nil pointer dereference [signal 0xb code=0x1 addr=0x0 pc=0xbedd] goroutine 14297 [running]: github.com/jbenet/go-ipfs/exchange/bitswap/decision.(*taskQueue).Remove(0xc2087553a0, 0xc2085ef200, 0x22, 0x56f570, 0xc208367a40) /Users/btc/go/src/github.com/jbenet/go-ipfs/exchange/bitswap/decision/taskqueue.go:66 +0x82 github.com/jbenet/go-ipfs/exchange/bitswap/decision.(*Engine).MessageSent(0xc20871b5c0, 0x56f570, 0xc208367a40, 0x570040, 0xc208753d40, 0x0, 0x0) /Users/btc/go/src/github.com/jbenet/go-ipfs/exchange/bitswap/decision/engine.go:177 +0x29e github.com/jbenet/go-ipfs/exchange/bitswap.(*bitswap).send(0xc20871b7a0, 0x56f4d8, 0xc208379800, 0x56f570, 0xc208367a40, 0x570040, 0xc208753d40, 0x0, 0x0) /Users/btc/go/src/github.com/jbenet/go-ipfs/exchange/bitswap/bitswap.go:352 +0x11c github.com/jbenet/go-ipfs/exchange/bitswap.(*bitswap).taskWorker(0xc20871b7a0, 0x56f4d8, 0xc208379800) /Users/btc/go/src/github.com/jbenet/go-ipfs/exchange/bitswap/bitswap.go:238 +0x165 created by github.com/jbenet/go-ipfs/exchange/bitswap.New /Users/btc/go/src/github.com/jbenet/go-ipfs/exchange/bitswap/bitswap.go:66 +0x49e
License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
e6f0b17
to
fa6e63c
Compare
@whyrusleeping RFCR Overall, I really love the new design. In the batch job "send wantlist to providers", the de-duplication is well-executed. The priority queue stuff inside the decision engine is awesome too. Given the above commits, I'd say #438 is LGTM and RFM. The above commits represent the sum total of my feedback. I'm eager to get yours. I'm especially curious to get your feedback on this commit (discussing the potential future of the priority queue model): |
cc @jbenet |
addresses... https://github.com/jbenet/go-ipfs/pull/438/files#r21878994 License: MIT Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
All of this looks good to me!
My only concern with that, is that cancel requests should be send out as soon as possible to avoid duplicate block send/receives.
I want to do something along these lines 👍
👍 to this too. |
And adding onto that, I was up last night thinking when I should have been sleeping, and I want to give the ledgermanager the ability to request blocks by itself to try and gain good karma on the network. So, if a certain block is being requested frequently, we should request it too so we can rehost it. I think we can put this logic into the LedgerManager at some point. |
Bitswap Rounds CR suggestions #2
SGTM.
SGTM |
This commit was moved from ipfs/boxo@a50f784
This commit was moved from ipfs/boxo@a50f784
@whyrusleeping another round of suggestions. Let's keep this one open for the while.