Steven Allen
Steven Allen
As far as I can tell, not receiving a message causes us to broadcast the request, receive a bunch of duplicate blocks, and then _increase_ the split. This seems backwards.
We usually handle this by setting up the node as follows: 1. Instantiate the libp2p node, but don't start listening on addresses. 2. Instantiate any services that need libp2p. 3....
So, I tried to implement it and realized this just isn't going to work, or at least not "well" because your libp2p host may have received connections before it's listening...
> The output channel should have the same buffer as the input channel (I think?). I'm really not sure the _best_ way to do this. We could also just have...
> do you mean the size of the output channel buffer is the same as the size of the input channel buffer Yes. The question is really: how do we...
My concern is that bitswap will keep popping blocks off the queue until it starts downloading blocks. That means we need an infinite receive buffer _anyways_. Basically, the tradeoff is...
Yeah, this would require changes in the DAGService. We'd likely add an optional `StreamBlocks()` method. Is there a description somewhere of go-blockstream's design? I'd love to take a look.
Really, this *is* the correct format for `DagJSON` (that is the JSON IPLD format). Unfortunately, our APIs don't *use* `DagJSON` (they should but it's hard to fix that now). We...
It won't. That's not valid DagJSON. It *could* serialize to CBOR (in theory) but we currently restrict map keys to be strings (IIRC, this is a hold-over from the days...