payload size issues

1,211 views
Skip to first unread message

Tae Hong Park

unread,
Jun 16, 2015, 7:09:00 PM6/16/15
to webso...@googlegroups.com
Guys,

We are having issues with payload size when sending data from the client (websocket++) to the websocket server (node.js) via the send() method. For example:

client c;

...
// connection is successful
...
// then we want to send payload; p is char array type

c.send(hdl, p->Data(), p->Size(), websocketpp::frame::opcode::binary);


-------------


the above works perfectly fine for data that is < 2^16. But if data is greater than that, run() method/loop stops. Our understanding is that the payload size limit is "jumbo" as per:

static uint64_t const payload_size_jumbo = 0x7FFFFFFFFFFFFFFFLL;//2^63   


Many thanks for any insights.


Best,

THP



Peter Thorson

unread,
Jun 16, 2015, 8:06:22 PM6/16/15
to Tae Hong Park, webso...@googlegroups.com
Do you have the error code that the connection ended with? You could either get this from the logging system or via registering a close handler and looking it up there.

Websocket++ has a max message size that is (usually) less than the protocol max message size to aid in fighting resource exhaustion and denial of service attacks. The default I think is 32MB, you can change this to be larger or smaller via endpoint::set_max_message_size.
--
You received this message because you are subscribed to the Google Groups "WebSocket++" group.
To unsubscribe from this group and stop receiving emails from it, send an email to websocketpp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Tae Hong Park

unread,
Jun 17, 2015, 8:57:04 AM6/17/15
to webso...@googlegroups.com
Thanks for the quick response. Yes, here's the error message:

[2015-06-17 01:03:23] [disconnect] Disconnect close local:[1009,Frame size of 65537 bytes exceeds maximum accepted frame size] remote:[1009,Frame size of 65537 bytes exceeds maximum accepted frame size]

It loos like it is the "frame size" where the issue is. The message size is 32MB as you correctly stated. Not sure how to go about increasing "frame size" or what the best approach would be for this situation. Thanks!

Peter Thorson

unread,
Jun 17, 2015, 9:36:00 AM6/17/15
to Tae Hong Park, webso...@googlegroups.com
This indicates to me that it is actually the server that is rejecting the frame not the websocket++ client. Are you able to send data this large from other websocket clients? Have you checked the max frame/message size for your server?

Tae Hong Park

unread,
Jun 17, 2015, 9:38:38 AM6/17/15
to webso...@googlegroups.com
Interesting ... that was going to be my next thing to look into. Does not seem to be the case but will look more closely. Thanks again for the quick feedback. More soon ...


On Tuesday, June 16, 2015 at 7:09:00 PM UTC-4, Tae Hong Park wrote:

Peter Thorson

unread,
Jun 17, 2015, 9:54:47 AM6/17/15
to Tae Hong Park, webso...@googlegroups.com
A note on frame vs message limits.

WebSocket messages are made up of individual frames. Frames have a protocol max size of 2^63. Messages have an unlimited number of frames and thus an unlimited size (the intent here was to allow indefinite streaming if needed).

WebSocket++ does not have any per frame limits because I don’t see any point to them. Per frame limits without per message limits still expose an endpoint to memory exhaustion via many max size frames. As such WebSocket++ has a max message size that represents the largest message that the endpoint will buffer in memory before closing the connection. The frame that would put the buffered-so-far message above the limit will trigger the closing of the connection with the 1009 code.

For security reasons (preventing attackers from easily reading the exact message size limit) WebSocket++ does not include the limit in the error message. WebSocket++ also will never even send a message that violates its own max message size limits, instead the send call will fail. These facts indicates to me that WebSocket++ did not generate that error message and is just relaying what the remote endpoint decided.

Tae Hong Park

unread,
Jun 17, 2015, 7:25:19 PM6/17/15
to webso...@googlegroups.com, th...@nyu.edu
Many thanks for the info. It was indeed server side frame size limits. Changed config and we are in business! Thanks!
Reply all
Reply to author
Forward
0 new messages