GitLab

Or, really, just avoid accessing it. We don't need it.

This caused a concurrent map access panic under load.

* fix: use one less go-routine per session

* fix: send cancel when GetBlocks() is cancelled (#383)

* fix: send cancel when GetBlocks() is cancelled

* fix: in SessionManager shutdown nil out sessions

* fix: sessionWantSender perf

* make sessionWantSender.SignalAvailability() non-blocking

* Refactor SessionInterestManager (#384)

* refactor: customize SessionInterestManager

* refactor: SessionInterestManager perf

* fix: ensure broadcast when peer becomes unavailable and all other peers sent DONT_HAVE for CID

* fix: lint warnings

* refactor: simplify session want sender DONT_HAVE list

* fix: flaky test

* test: add session exhausted wants test

* docs: improve sessionWantSender processAvailability docs

This makes reading the docs much easier as it's clear what's "private" and
what's not.

fixes #238

This commit extends the bitswap protocol with two additional wantlist properties:

* WANT_HAVE/HAVE: Instead of asking for a block, a node can specify that they
  want to know if any peers "have" the block.
* WANT_HAVE_NOT/HAVE_NOT: Instead of waiting for a timeout, a node can explicitly
  request to be told immediately if their peers don't currently have the given
  block.

Additionally, nodes now tell their peers how much data they have queued to send
them when sending messages. This allows peers to better distribute requests,
keeping all peers busy but not overloaded.

Changes in this PR are described in: https://github.com/ipfs/go-bitswap/issues/186

We're not using these synchronously so we can buffer them a bit to avoid
blocking quite as much.

This also combines all incoming channels into a single one to ensure all
operations are processed in-order. This might be overkill bit it makes reasoning
about this a bit simpler.

feat: process response message blocks as a batch

send duplicate responses to the session peer manager to track latencies

Better estimate latency per peer by tracking cancellations

When fetching optimized peers from the peer manager, return an optimization rating, and pass on to
request splitter

BREAKING CHANGE: interface change to GetOptimizedPeers and SplitRequests public package methods

This fixes the case where:

1. I start downloading something.
2. A friend jumps on our WiFi.
3. Our IPFS daemons connect via local discovery.
4. I never notice that they have the file I'm looking for because I'm already downloading it from a peer.
5. The peer I'm downloading from is _really_ slow.

Re-setup provider search delay and rebroadcast delay on a per bitswap instance basis

Don't count consecutive ticks if there are no active wants

on a tick, do not keep searching for providers for the same block. instead rely on a periodic search
for more providers. (which will run no matter what, even w/o ticks, to optimize found providers).
also backoff tick time to reduce broadcasts.

fix #95, fix #107