-
Notifications
You must be signed in to change notification settings - Fork 238
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
use a new stream per request #167
Conversation
Note: This PR is intentionally inflammatory and exists for discussion. |
5b8d632
to
ec82cc6
Compare
ec82cc6
to
c0ae05f
Compare
show me the numbers |
One stream per request:
Pipelined:
Note: the timing can vary by up to a second. However, this patch is definitely faster in the mock net. However, I don't know why we switched away from using one stream per request in the first place. |
And bandwidth usage? (as tracked by the OS) |
30%? WTF multistream select! One of my plans for the libp2p meetup is to improve multistream-select. I'll add "low overhead" to the list. Ideally, identify would negotiate connection specific aliases that are just varints. |
Yeah... this is why I did the stream reuse stuff in the first place. It makes me sad. Hear that @jbenet ?? SAD |
Why was this closed? Was it due to extra bandwidth requirements? |
Yes. |
"pipelining is hard, painful, and error-prone" is a key reason browsers gave up on it and started implementing stream muxing.
Guess what, we have stream muxing!
Now, this is what we used to do (i.e., we used to use one stream per request).
There are two reasons not to:
In terms of performance, I had to remove the lower latency bound in the test cases to get them to pass.