Before, the engine worker would pop a task and block on send to the
bitswap worker even if the bitswap worker wasn't to receive. Since the
task could have been invalidated during this blocking send, a small
number of stale (already acquired) blocks would be send to partners.
Now, tasks are only popped off of the queue when bitswap is ready to
send them over the wire. This is accomplished by removing the
outboxChanBuffer and implementing a two-phase communication sequence.
refactor: peerRequestQueue
it's a mistake to make one queue to fit all. Go's lack of algebraic
types turns a generalized queue into a monstrosity of type
checking/casting. Better to have individual queues for individual
purposes.
Conflicts:
exchange/bitswap/decision/bench_test.go
exchange/bitswap/decision/tasks/task_queue.go
fix(bitswap.decision.PRQ): if peers match, always return result of pri comparison
fix(bitswap.decision.Engine): push to the queue before notifying
TOCTOU bug
1. client notifies
2. worker checks (finds nil)
3. worker sleeps
3. client pushes (worker missed the update)
test(PQ): improve documentation and add test
test(bitswap.decision.Engine): handling received messages
License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
I think it's time to move a lot of the peer-to-peer networking
but-not-ipfs-specific things into its own package: p2p.
This could in the future be split off into its own library.
The first thing to go is the peer.
@whyrusleeping @jbenet this is a WIP with the DHT.
wip
License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
Conflicts:
epictest/addcat_test.go
exchange/bitswap/testnet/peernet.go
exchange/bitswap/testutils.go
routing/mock/centralized_server.go
routing/mock/centralized_test.go
routing/mock/interface.go
fix(routing/mock) fill in function definition
Had to change the network interface from DialPeer(peer.ID) to
DialPeer(peer.PeerInfo), so that addresses of a provider are
handed to the network.
@maybebtc and I are discussing whether this should go all the
way down to the network, or whether the network _should always
work_ with just an ID (which means the network needs to be
able to resolve ID -> Addresses, using the routing system.
This latter point might mean that "routing" might need to
break down into subcomponents. It's a bit sketchy that
the Network would become smarter than just dial/listen and
I/O, but maybe there's a distinction between net.Network,
and something like a peernet.Network that has routing
built in...)
https://build.protocol-dev.com/job/race/9352/console
@jbenet @whyrusleeping
pinging you guys to spread awareness about the delay.D type for
configurable delays
License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>
