Go-ipfs: Refactoring Bitswap

[Kubuxu]

Bitswap is currently complex system that grew organically. In short terms it is quite a mess, in longer we are using a lot of different programming and communication patterns and it is just big.
It has problems with limiting concurrency (we sometimes see bitswap goroutine explosions). We have almost no introspect on the performance, latencies and effectiveness of its components. Finally, it is quite a mess of code already.

In my opinion we should draw out spec/behavioural model of bitswap and re-implement it cleanly with some goals in mind.

One thing I would love to see is clear model of bitswap and implementation that can be followed and reasoned about.

Currently Bitswap implementation is using mix of multiple programming pragmatism, starting with Go style communication by channels (sync and async), through some shared/locked maps and sets, message queues and dispatchers (actor model) and possibly many more.

What seems to fit Bitswap the best is Actor model. In most cases we want the queries to Bitswap to be fully async (this means message queues) and we have multiple tiers of different workers we want to dispatch some work to (finding providers, connecting to peers, updating the wantlist, responding to want list requests and so on).

Using Actor model would give us following benefits:

1. limited and scalable concurrency (unlimited concurrently has bitten us many times over)
2. better introspection into the structure and connections
3. possibility of implementing backpressure in some places
4. native support for fully async messages, message queues and dispatchers

I have recently tried improving concurrency limitations of the DHT, Dial and Connection workers in Bitswap and Actor model would be perfect for it, we even in once case implement one instance of Actor but it is manual and can't be reused.

[whyrusleeping]

I also think that bitswap should no longer actually perform any providing on its own. All content providing should be handled by its own thing. That would reduce a lot of the complexity going on in bitswap right now

[Stebalien]

@whyrusleeping So, break it into three services?

• Client (finds objects)
• Server (provides/serves objects)
• Ledger/Engine (keeps track of peer "goodness").

[whyrusleeping]

@Stebalien Yeah, I think that alongside your effort to clarify the dag/blockstore/nodestore we can also clarify the boundaries between the different parts of bitswap. The engine, the wantmanager, the main 'bitswap' thing, and the 'network'. Its a bit muddied right now and could definitely use some love.

[hx1015]

What is the impact of bitswap ledger on the next block exchange? Has it been implemented in the code?

[Stebalien]

Not yet.

[Stebalien]

We have now refactored bitswap to use an actor model (ish). Unfortunately, it's no simpler.

(closing this issue as stale)

[hx1015]

We have now refactored bitswap to use an actor model (ish). Unfortunately, it's no simpler.

(closing this issue as stale)

Thank you very much.