-
Notifications
You must be signed in to change notification settings - Fork 154
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
WebSocket streaming API #280
Comments
Is |
It doesn't because it does not expose the length of the message upfront. For any effective length prefixed messaging, we need to know the length of the message upfront, also exposing a reader object would mean that So I could essentially do OnMessageStream(messageType int, messageLength int, reader io.Reader) {
yamuxStream.Write(intToBytes(messageLength))
io.Copy(yamuxStream, reader)
} |
The |
And maybe another way: since your backend is handling stream, how about adding a |
I am not sure if that's true, a websocket message does contain the length of the message in the first few bytes, see https://www.openmymind.net/WebSocket-Framing-Masking-Fragmentation-and-More/ -- we just need to find a way to expose that in the API |
That's not |
So I found an alternative: Just forward the wire level bytes from |
I don't think it's a good idea to use gobwas/ws in production, for more details: One more thing, OnDataFrame may be better. |
Do note I only use gobwas to parse websocket wire-level messages which are sent from front-facing proxy over a multiplexed yamux transport, this essentially allows me run websocket on top of Yamux. The front-facing proxy is still NBIO |
That's fine. |
To reduce the total memory usage, Related: |
I have a websocket reverse proxy that forwards websocket messages from clients to a backend server. The front-facing server is based on NBIO WebSocket AND the backend instance is based on Yamux (https://github.com/hashicorp/yamux).
Due to the message oriented nature of websocket, it doesn't really have any backpressure, so it becomes quite easy to exhaust the server. It also results in increase memory footprint because a full websocket message has to be buffered first and only then we can forward that message to the backend server.
NBIO should expose an optional API, that exposes length of the websocket message upfront AND provides a "reader" object that can be read from. This would allow to translate any incoming websocket message into a length prefixed messaging scheme that I can use to forward to the yamux server, this will obviously reduce the memory footprint and due to the streaming nature, it will be possible to apply TCP backpressure as well
The text was updated successfully, but these errors were encountered: