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

Add to js-ipfs bundles #7

Closed
6 tasks done
jacobheun opened this issue Feb 13, 2019 · 6 comments
Closed
6 tasks done

Add to js-ipfs bundles #7

jacobheun opened this issue Feb 13, 2019 · 6 comments
Assignees
Labels
P1 High: Likely tackled by core team if no one steps up status/in-progress In progress

Comments

@jacobheun
Copy link
Contributor

jacobheun commented Feb 13, 2019

This issue is for tracking the release of pull-mplex into js-ipfs, as a replacement for libp2p-mplex.

@jacobheun jacobheun added P1 High: Likely tackled by core team if no one steps up status/in-progress In progress labels Feb 13, 2019
@jacobheun jacobheun self-assigned this Feb 13, 2019
@daviddias
Copy link
Member

@jacobheun it would be great if pull-mplex (or future async/generators-mplex) was just the internals libp2p-mplex. There should be no need to have multiple concurrent implementations, there should just be, however, tons of tests to ensure the soundness of each of these migrations as Stream Muxing has been historically a PITA.

@daviddias
Copy link
Member

For example, make sure to run the mega stress test https://github.com/libp2p/interface-stream-muxer/blob/master/src/mega-stress-test.js#L7 and compare both implementations.

@jacobheun
Copy link
Contributor Author

it would be great if pull-mplex (or future async/generators-mplex) was just the internals libp2p-mplex.

I agree. It was a bit easier to test the two side by side being separate but there are other ways to do that, but the new implementations should just be the libp2p-mplex internals. I think the stream muxers need more test in general, it's difficult to debug issues when they arise, so avoiding as many of those as possible up front with more in depth testing is ideal.

Some mega stress test comparison runs:

libp2p-mplex pull-mplex % Faster
1475641ms 1022068ms 30.74%
1247929ms 1083919ms 13.14%
1563942ms 1078838ms 31.02%

@daviddias
Copy link
Member

@jacobheun those are great results!

new implementations should just be the libp2p-mplex internals.

Can this be done before importing it into js-ipfs bundle?

@jacobheun
Copy link
Contributor Author

Can this be done before importing it into js-ipfs bundle?

It's already in the bundle and it's slated to get released with js-ipfs 0.36, which I believe is going out today.

@daviddias
Copy link
Member

For those following, there is a new mplex version using those HAWT async iterators at libp2p/js-libp2p-mplex#94

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/in-progress In progress
Projects
None yet
Development

No branches or pull requests

2 participants