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

[feature] Max send frame size #814

Open
tigrannajaryan opened this issue Sep 20, 2022 · 3 comments
Open

[feature] Max send frame size #814

tigrannajaryan opened this issue Sep 20, 2022 · 3 comments

Comments

@tigrannajaryan
Copy link

Problem Description

Some WebSocket implementations have trouble receiving large frames. Fir example AWS API Gateway cannot receives frames larger than 32KB.

When sending large messages to such implementations the sending typically fails since gorilla websockets do not normally slice large messages and send them as one frame.

Possible Solution

It would be great to add an option to specify the maximum frame size in the client and in the server. We already have WriteBufferSize which when sending small messages acts as the frame size limit (we accumulate messages up to WriteBufferSize bytes and send them in one frame).

A WriteMaxFrameSize option would be a nice addition to the Dialer and Upgrader. The WriteMessage and NextWriter.Write calls would honour the WriteMaxFrameSize setting.

Alternate Solution

Currently if you use NextWriter.Write you can control the frame size to some degree. This is because NextWriter.Write sends the frame as soon as the write buffer is full. So, by setting a desired WriteBufferSize one can slice the payload in the application and then repeatedly call NextWriter.Write calls to make sure each portion is delivered as a separate frame.

This is however undocumented implementation detail. An alternate solution would be document this behavior and explain how one can use it to control the frame size.

@ghost
Copy link

ghost commented Sep 21, 2022

We need more than one frame per message when sending a large message to AWS. We need exactly one frame per message when sending a compressed message to Safari. What a world we live in!

I took a look at the code. You should be good with multiple write calls as a workaround for this issue.

@tigrannajaryan
Copy link
Author

I took a look at the code. You should be good with multiple write calls as a workaround for this issue.

@volkerite yes, I did check the code and that's how it works currently. However, as far as I can tell this specific behavior is not documented. If it is expected that this is how NextWriter.Write should work then it would be great to have this documented so that I can rely on it.

@ghost
Copy link

ghost commented Jun 15, 2024

An alternative to MaxFrameSize is to add a Flusher interface to package and support that interface on writers.

type Flusher interface {
	// Flush sends any buffered data to the client.
	Flush() error
}

Applications can limit frame size by flushing as appropriate.

I am not convinced that Flusher is better than OP's MaxFrameSize proposal. I am just throwing this out for consideration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

3 participants