GitLab

log(bitswap) remove ambiguous event

@jbenet @whyrusleeping

With these notifications, bitswap can reclaim all resources
for any outstanding work for a peer.

cc @briantigerchow @whyrusleeping

@whyrusleeping

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.

Bitswap doesn't usually care about dialing. the underlying
network adapter can make sure of that.

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.

@jbenet @whyrusleeping

This commit replaces peer.PeerInfo with peer.ID in the bitswap package

@jbenet @whyrusleeping

the next commit will change bitswap.Network.FindProviders to only deal
with IDs

cc @whyrusleeping

This reverts commit bf88f1aec5e3d397f97d64de52b52686cc7a8c8f.

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...)