You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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 toWriteBufferSize
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 theWriteMaxFrameSize
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.
The text was updated successfully, but these errors were encountered: