[WIP] feat: initial implementation of pull-streams based multiplexer

[dryajov]

the multiplexer itself is being implemented as a separate module under libp2p/pull-mplex#1. This is done for reusability purposes but it should be moved under the libp2p org at some point.

[dryajov]

NOTE: I've added pull-mplex as a git dep, so that we can test with it across different dependencies. This is temporary and should be changed once pull-mplex is released.

[coveralls]

Pull Request Test Coverage Report for Build 216

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 5 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+9.02%) to 87.5%

---

Files with Coverage Reduction	New Missed Lines	%
../src/index.js	2	91.3%
../src/muxer.js	3	84.38%

Totals
Change from base Build 212:	9.02%
Covered Lines:	47
Relevant Lines:	52

---

💛 - Coveralls

[daviddias]

I want to preserve both implementations and make it easy to switch between both and have benchmarks in this repo. This translates to:

• Benchmarks in this repo that compare both
• Tests that test one implementation against the other using interface-stream-muxer tests
• Only publish to npm the deps for the version that we want users to use and have the other version deps as devDeps

[dryajov]

Ok, most of this is already in pull-mplex and can/should be moved. There are integration tests for the previous and new versions, as well as benchmarks, also this already runs against interface-stream-muxer tests.

I'll move them over to this repo.

[daviddias]

Sounds good! Thank you :)

[mkg20001]

@dryajov What's the status of this pr? Is it going to be continued? Is it superseded by pull-mplex?

[dryajov]

yes it is, but being that pull-streams are being replaced in favor of async iterators, I wonder if it makes sense anymore.

[mkg20001]

@dryajov ws-star is also "getting replaced" by rendezvous, yet the progress on that is so fast that I decided to just build stardust.

Also wouldn't it make sense to have this much effort in production at least for a couple weeks? Better late than never ;)

[dryajov]

@mkg20001 I agree, I would very much love to see this in prod, but I doubt I'll be able to finish it at this point or there is time from the rest of the team to review it, plus the move to async, might make the pull-stream approach obsolete altogether. Although, it might be a good benchmark to compare against along size node streams.

As a start tho, can we get a preliminary review of pull-mplex and this?

[daviddias]

For the reader:

• the pull-streams version now lives at https://github.com/libp2p/pull-mplex
• the new libp2p-mplex is all about those async iterators, found refactor: async iterators #94