Multiplexed websocket support

[jared2501]

Currently, if using grpc-web with client-streaming (and bi-directional) endpoints one has to use the the websocket implementation provided by grpc-web since no fetch implementation supports client streaming yet. The websocket implementation in grpc-web opens a websocket per stream. Since each websocket is a separate, long-lived TCP stream, Firefox currently allows a maximum of 6 websockets per host. It would be nice if multiple gRPC streams could be multiplexed over a single websocket.

A rough proposal for what this could look like:

• Each websocket binary message becomes a tuple of (streamId, bodyBytes|controlFrame). The controlFrame would be used to signal protocol errors / end of stream.
• The streamId provides a means to multiplex multiple connections over a single websocket. It would behave exactly like an HTTP/2 stream ID - clients generate successive odd numbers when initiating new streams (servers would generate successive even numbers, but would not be supported in grpc-web).
• The headers included at the start of a stream would include a ":path" entry, rather than the path of the websocket being used.

[jared2501]

I'm looking to build such a transport on an internal fork this week. If this proposal sounds good, I'd be happy to contribute it back.

[joa]

@jared2501: Did you make any progress or is there a repo where we'd could provide some support?

[johanbrandhorst]

Bump, this would be a great addition.

[RobIsHere]

I stumbled across this project: https://github.com/rsocket/rsocket/blob/master/Protocol.md
They are also solving multiplexing on websocket and have a very sophisticated protocol definition.

[davedoesdev]

I stumbled across this issue, thought I'd mention in passing a couple of projects I did:

https://github.com/davedoesdev/bpmux
https://github.com/davedoesdev/primus-backpressure

They implement back-pressure and multiplexing over Primus (WebSocket) streams.

I don't think they're highly relevant here but thought I'd mention them in case you find something useful.

[anderspitman]

I hadn't heard of rsocket before seeing @RobIsHere's comment, and not for lack of searching for something in this space. I've been working on what could be considered a very stripped down version of the same idea. After reading through their info I think rsocket would likely be a great solution if you want to implement this functionality.

[wuyuanyi135]

+1 on this feature. The connection limit forced me change the architecture of my project.

[Virtual-felix]

+1 it would be a very appreciable improvement

[jonnyreeves]

If anyone has some time to work on a proposal / implementation it would be greatly appreciated.

…

On Mon, 11 Nov 2019 at 16:16, Fabrega Felix ***@***.***> wrote: +1 it would be a very appreciable improvement — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#198?email_source=notifications&email_token=AABQ36N3B2AFRC3ZVFLD3HTQTGANNA5CNFSM4FCJHAD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDXKB5Y#issuecomment-552509687>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABQ36J5BZY3RRMM4NIRX6DQTGANNANCNFSM4FCJHADQ> .

[maciej-wolny]

Any updates on the topic?