Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature: ability to override default bitswap max message size #152

Closed
wants to merge 25 commits into from

Conversation

ya7ya
Copy link

@ya7ya ya7ya commented Sep 27, 2017

This PR is a part of the fix for the browser to browser file transfer issue in IPFS ipfs/js-ipfs#1019 .

This edit allows an override of MAX_MESSAGE_SIZE so it can be used in the browser via WebRTC Transport. I been testing and so far 32KB seem to work in the browser without getting throttled.

License: MIT
Signed-off-by: Yahya ya7yaz@gmail.com

License: MIT
Signed-off-by: Yahya <ya7yaz@gmail.com>
@codecov
Copy link

codecov bot commented Sep 27, 2017

Codecov Report

Merging #152 into master will increase coverage by 0.96%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #152      +/-   ##
==========================================
+ Coverage   91.16%   92.13%   +0.96%     
==========================================
  Files          14       14              
  Lines         736      661      -75     
==========================================
- Hits          671      609      -62     
+ Misses         65       52      -13
Impacted Files Coverage Δ
src/decision-engine/index.js 94.96% <100%> (+6.59%) ⬆️
src/index.js 82.14% <100%> (+0.12%) ⬆️
src/want-manager/index.js 88.13% <0%> (-6.78%) ⬇️
src/types/wantlist/index.js 92.85% <0%> (-3.58%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6175f9c...f9d21c4. Read the comment docs.

@ya7ya
Copy link
Author

ya7ya commented Oct 9, 2017

hey @diasdavid , Can you take a look at this PR?
This minor modification allows bitswap to change MAX_MESSAGE_SIZE so it can be used in the browser via WebRTC Transport. I been testing and so far 32KB seem to work in the browser without getting throttled.

Let me know what you think.

Copy link
Member

@daviddias daviddias left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @ya7ya, this overall LGTM, just needs 2 more things:

  • Interop tests to be added at the js-ipfs level. By dropping the max message size, we need to ensure that we still accept go-ipfs sent messages (and other nodes that didn't change this factor)
  • Documentation update (through jsdoc)

@Stebalien
Copy link
Member

@diasdavid shouldn't this be handled by the WebRTC transport?

…e nodes

License: MIT
Signed-off-by: Yahya <ya7yaz@gmail.com>
@daviddias daviddias added status/ready Ready to be worked P1 High: Likely tackled by core team if no one steps up labels Oct 13, 2017
pgte and others added 13 commits November 8, 2017 16:03
* added missing multicodec dependency

* using ~ for multicodec dependency range because version < 1
* test: close IPFSRepo before deleting its files

* chore: run on appveyor

* chore: upgrade packages

* chore: debugging appveyor failure

* test: more appveyor debugging

* test: use os.tmpdir() not '/tmp'

* test: timeout issue

* test: fix error reporting

* test: Math.Random => uuid

Math.Random can create collisions.  Using uuid should not create a collision.

* test: all tests can timeout, need global timeout specified

* test: bitswap-mock multi peer is just too long, skip it

* fix package.json

* test: ipfs@0.18.3 breaks us.  reverting to 0.18.2

* chore: update repo version

* chore: update deps

* bring back the test
This commit updates all CI scripts to the latest version
* bitswap stats: async updater

* linter happy

* pre-commit hook for linting and tests

* stats: support dataReceived

* stats: data received

* stats: blocks sent and data sent

* stats: using bignum

* stats: compute throttle with threshold

* stats: update timeout is now dynamic based on queue size

* stats: moving averages

* stats: providesBufferLength

* stats: support for providesBufferLength and wantListLength

* stats: support for peerCount

* stats: enable / disable

* increased test timeout
* getMany: guaranteed ordering

* tests: swarm, humble beginnings

* chore: added test for when no cid is passed in

* chore: more swarm tests

* tests: serializing interconnections on swarm tests

* more swarm tests enabled

* tests: removed some onlys

* tests: serializing interconnections on swarm tests

* tests: added double get test

* chore: added test for double get

* one less callback function

* chore: update libp2p version to latest

* chore: update remaining deps
@daviddias
Copy link
Member

@ya7ya is this PR something you still think you can finish?

* fix: getMany: ensuring we set the want list independently of having all blocks or not

* bitswap stats tests: not requiring specific order to finish

* increasing the timeouts of swarm tests
@ya7ya
Copy link
Author

ya7ya commented Jan 28, 2018

@diasdavid Hey david, I completely forgot about this PR, I'm so sorry about this. I'll try to finalize this and add the required tests as soon as possible. 🙇

* docs: current stats API documented

* per peer stats
@Stebalien
Copy link
Member

There are a lot of changes here so it's a bit hard to tell what this is actually doing now but, if this is doing what the title says, this is very much the wrong fix. Is it really not possible (and much simpler) to have the WebRTC transport write at most 32KiB at a time?

@ya7ya
Copy link
Author

ya7ya commented Feb 6, 2018

hey @Stebalien , I rebased this PR to master so that's why there are alotta changes.

if this is doing what the title says, this is very much the wrong fix.

Yes. This does what the title says. And I'd be very interested in doing the correct fix and rejecting this PR if it's possible to override this at webRTC transport level.

@Stebalien
Copy link
Member

It should be fairly easy to fix in the webRTC transport. Unfortunately, my understanding of js streams is rather limited (I generally avoid working on javascript).

@ya7ya
Copy link
Author

ya7ya commented Feb 6, 2018

@Stebalien I'm gonna look into it. probably we can throttle the pull request conn in the Transport itself. I'm not 100% sure but I'll see what I can do. Thanks for the tip, I appreciate your input 👍 💯

@dryajov
Copy link
Member

dryajov commented Feb 7, 2018

@ya7ya I believe, we can use something like this to chunk the stream at the transport level - https://pull-stream.github.io/#pull-block.

@alanshaw
Copy link
Member

+1 this needs to be handled in the webrtc libp2p transport.

@daviddias
Copy link
Member

@vasco-santos, @jacobheun this PR suggests that the transports should get some benchmarking treatment.

There are two low hanging fruits to make things fast:

  • The change that @ya7ya suggests for the WebRTC transport
  • Creating a simple-peer module that doesn't rely on Readable Streams

@achingbrain
Copy link
Member

I don't think this PR is necessary any more, the upstream issue it's supposed to fix has been addressed by libp2p refactors.

Please feel free to reopen if it's still a problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

9 participants