Closed aschmahmann closed 2 years ago
Since the server is simpler to implement than the client, I'm starting with the server. I'm also holding Testground tests as a hard requirement for measuring performance. After that, I can look into disabling server functionality on the existing impl, so that we are left with a server and a client.
The last piece then would be some sort of server-client bridging component which combines the two into something resembling the existing interfaces, which @Jorropo is working on.
@Jorropo @guseggert : what is remaining in this issue that wasn't accomplished in https://github.com/ipfs/go-bitswap/issues/568 ?
@BigLep I actually finished this while I was doing #568, this is done. #567 can stand alone.
While it's very nice that we have the protobufs and general message parsing code in a separate package it's unfortunate that go-bitswap insists on instantiating client (sending out wants) and server (receiving and responding to wants) behaviors together. We should have an abstraction that allows us to separately create client and server implementations as well as combine them together.
Some of the benefits we'd get here include:
A couple of the tricky pieces to untangle here are: