go-ipfs seams to rebroadcast the want list on a fixed interval.
In JS, there is a rebroadcastDelay defined in src/constants.js, but it's not being used.

Should we implement a rebroadcast?
If all the changes in the waitlist get broadcasted, why would a node get out of sync (unless the transport is somehow unreliable, which would be a more troubling issue...)?

@whyrusleeping do you have any insight on this?

Due to CI being suuuper slow the browser tests time out while cleaning up databases. Resulting in a browser restart, making CI report red :( .Need to figure out how to fix this :(

Version 0.8.2 of peer-id just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As peer-id is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 2.2.3 of multiaddr just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As multiaddr is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

As asked here: #76

Is a MessageQueue per peer the best approach? Why not piggyback on want list updates and just check what the peer wants and attach the blocks necessary?

It might be tad expensive to have a message queue for each peer, especially with a lot of Peer Churn

Uncaught TypeError: Big is not a function
    at Stats.initialCounters.forEach (stat.js?ce0f:22)

This happens because Big.js uses now default export.

Currently, in peer-crdt, the latency of replication of logs is bound to the latency of getMany(cids) when the blocks are not present.

Also, I think we should create benchmarks to have a baseline we can try to improve on.

Avoid using: https://github.com/ipfs/js-ipfs-bitswap/blob/master/package.json#L45

Context: libp2p/js-libp2p#92

Version 0.17.9 of libp2p-ipfs-nodejs just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As libp2p-ipfs-nodejs is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 2.1.4 of benchmark just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As benchmark is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

stats (exchanged byteCount and so on) kind of don't have any self-guards to overflowing

I believe that we should have a way for stats to be disabled and at the same time, make it so they are updated asynchronously, these are just shared values that are mutated with incrementations, which makes it very safe to defer.

Another things is to use a bignum library, otherwise it will get weird in long-running nodes.

Version 0.3.1 of peer-book just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As peer-book is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 0.17.10 of libp2p-ipfs-nodejs just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As libp2p-ipfs-nodejs is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

• Use ipfsd-ctl to spawn go-nodes
• Spawn js-ipfs-bitswap instances
• Connect all of them
• Exchange blocks

We want all these tests ported: https://github.com/ipfs/go-ipfs/blob/master/exchange/bitswap/bitswap_test.go

Depends on #8

• parallel and each => run-parallel
• series and eachSeries => run-series
• parallelLimit and eachLimit => run-parallelLimit
• setImmediate => global.setImmediate (shimmed through core-js already)
• queue => need more research

Version 2.3.0 of multiaddr just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As multiaddr is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 11.0.1 of aegir just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As aegir is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 0.3.2 of peer-book just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As peer-book is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 2.1.5 of async just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As async is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 0.4.1 of cids just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As cids is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Saw this on #149

and

Ref: #76

Why have two classes for WantListEntry? The BitSwapMessage Entry only has one more property cancel, can't we just extend the other and add that property?

Version 2.3.0 of async just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As async is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Documenting things here.

Version 0.8.5 of peer-info just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As peer-info is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

We don't use it that much and it brings in 127.8 KB of size into the bundle.

Version 0.5.5 of ipfs-block just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As ipfs-block is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 0.4.5 of multihashing-async just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As multihashing-async is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

I think we should define some performance requirements for bitswap (like, for example: "for 10 bitswaps exchanging 1000 blocks between themselves, they must execute this in X seconds or less"), and then apply these to the already existing test/benchmarks.

This is almost done (test/benchmarks already can be parametrised to spawn a network of x nodes exchanging y blocks), so I think this is just a matter of defining the baseline to:

a) prevent performance regressions
b) incorporate improvements

@victorbjelkholm @vmx Thoughts on this?

Version 0.21.1 of libp2p-ipfs-nodejs just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As libp2p-ipfs-nodejs is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

As per ipfs/team-mgmt#600, please list yourself as the Lead Maintainer

Version 0.18.2 of libp2p-ipfs-nodejs just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As libp2p-ipfs-nodejs is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Hey @dignifiedquire i have some questions re impl. Forgive silliness, first time i look at it.

1. why is bitswap block key going to hex in the proto msg? it should be straight binary -- https://github.com/ipfs/js-ipfs-bitswap/blob/master/src/message/index.js#L48
2. why bitswap.stop has this.network.start() https://github.com/ipfs/js-ipfs-bitswap/blob/master/src/index.js#L276
3. why bitswap.network uses bl? isnt this wasteful? is it caching all buffers? (i've only glanced at bl, havent used it) https://github.com/ipfs/js-ipfs-bitswap/blob/master/src/network/index.js#L40
4. provierRequestTimeout spelling - https://github.com/ipfs/js-ipfs-bitswap/blob/master/src/constants.js#L7

Congratulations on having the top result at duckduckgo.com query: bitswap protocol .. Can you add a link to the main page to help users find more high level docs on the topic? tq

Hey @diasdavid and the IPFS team, I'm building something that requires getting a notification from bitswap._notification and noticed that it doesn't have more generic events, events are triggered with a string that includes the block.cid usually. so creating a listener that listens to all block:* isn't that straightforward.

What if instead of using something like eventemitter2 that adds wildcard and other functionalities , we can just trigger a more generic event like so

// current implementation (notification.js)
hasBlock (block) {
    const str = `block:${block.cid.buffer.toString()}`
    this._log(str)
    this.emit(str, block)
 }

// proposed change
hasBlock (block) {
    const str = `block:${block.cid.buffer.toString()}`
    this._log(str)
    this.emit(str, block)
    // generic event
    this.emit('block', block)
}

What do you think?? Is this something you'd be interested in adding or not?

We need these stats per peer because of ipfs-inactive/dynamic-data-and-capabilities#3 and ipfs/js-ipfs#1198.

Version 2.2.1 of multiaddr just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As multiaddr is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Fire N number of nodes and connect all of them together

• see: https://circleci.com/gh/ipfs/js-ipfs-bitswap/402

Need to

• check limit on incoming messages.
• split outgoing messages into multiple if they are large.

I feel that it requires a huge cognitive investment to dial into bitswap, before #76 there was not documentation making it hard to understand what is what. Also, there are a lot of design decisions that simply aren't clear from reading the code and once you start describing them, you realise that it can be so much more improved (as also noted in #76).

I would like for bitswap to reach a state where it is just obvious to understand how it works, how to improve it and how to use different bitswap strategies. I know there is some interest in the community to experiment with variations of bitswap.

I know this is a very abstract request, but there are some action items that we can start with:

• Make code more modular (reduce size of files, right now it requires a lot of scrolling)
• Improve documentation even further (graphs, more graphs :))
• Explain design rationale and reference material for contributors to get a good grasp of 'why it is this way'
• Have a way to visualise (like this http://mg8.org/processing/bt.html but better)

As noted in #76 (comment)

I don't see any code to coalesce messages in the messages queues, which means the more peers we have, the more buffering it will happen, to the point where the message to reset the wantlist might be added even before the previous having been sent and nothing is clearing the message queue.

This will improve performance and reduce the memory usage by a lot

Version 2.6.2 of debug just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As debug is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Sometimes we get this error in tests:

As noted in: #76

The decision engine buffers the blocks in memory when it informs the message queue that there is one more block to send, this means that if thousands of transfers are being performed, every block will stay in memory till the message gets sent. A better approach would be to only read from disk when the message is going to be sent.

With this, we might loose some perf by having to go read from disk, but that is why I created this issue ipfs/js-ipfs-repo#110 to add a LRU cache on the repo.

I've asked this in this issue #76

@dignifiedquire ?

Ref ipfs/kubo#3182

Version 0.11.3 of ipfs-repo just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As ipfs-repo is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴