top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

WebSocket message size limits

+3 votes
1,572 views

I am looking for help in understanding why the size of the inbound WebSocket message is limited to 125 bytes. I realize that this may not even be the right place for my question, but am still hoping for a clue.

From looking at the RFC 6455, Sec. 5.2 Base Framing Protocol, I am making two conclusions:

  1. There's nothing in it to suggest a payload length asymmetry between inbound and outbound messages. Yet, although I am able to send very large messages to the browser, an attempt to send anything over 125 bytes results in error and a connection shutdown. (I tried FF and Chrome on a Mac).

  2. It's easy to see from the wire protocol why 125 is the simplest payload length but other sizes up to unsigned 64 bit int are supported. So, browser's failure to transmit more than 125 bits indicates both, the most restrictive payload size AND lack of support for fragmented messages.

The error that FF gives reads "The decoded text message was too big for the output buffer and the endpoint does not support partial messages" which to me reads like they are saying that Tomcat did not indicate during handshake that it accepts multi-part messages. True?

I can't speak for others, but for my project 125 bytes is unacceptably small. So, fundamentally what I need to know is this: do I need to implement my own fragmenting or am I missing something?

posted Sep 18, 2013 by Ahmed Patel

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote

Let me try to answer point by point -

1.I am looking for help in understanding why the size of the inbound WebSocket message is limited to 125 bytes.

It isn't, at least not by Tomcat.

2.The error that FF gives reads "The decoded text message was too big for the output buffer and the endpoint does not support partial messages" which to me reads like they are saying that Tomcat did not indicate during handshake that it accepts multi-part messages. True?

False. There is nothing in the handshake that allows one end not to support multi-part messages nor to limit the maximum message length.

That looks like a client side issue to me. Maybe you need to make the client side output buffer bigger.

Tomcat's web socket support (client and server) has been tested with the Autobahn testsuite that includes tests with significantly larger messages than 125 bytes both as single frames and as multiple frames.

3.The error that FF gives reads "The decoded text message was too big for the output buffer and the endpoint does not support partial messages" which to me reads like they are saying that Tomcat did not indicate during handshake that it accepts multi-part messages. True?

You are missing something. No idea what since you haven't provided any details of your client side implementation.

answer Sep 18, 2013 by Sanketi Garg
Similar Questions
+2 votes

Is there a standard way to access ServletContext from a WebSocket ServerEndpoint ?

+2 votes

In our current generation web application we used session replication with tomcat clustering. (and a load balancer). That way, we received an auto fail-over when a client sends an ajax request to a tomcat node that failed.

In our next generation web application, We would like to have a similar behavior, only with web-sockets. So my questions are :

1) Is it possible ?
2) Does it involve websocket-session replication? if so, are there any guides on how to do that?

+3 votes

As we start load testing our jsr-356 applications, I'd like to find out if there are any websocket-specific connector settings we should be aware of for tuning the underlying websocket connection processing. Since this is a tcp socket at the end of the day, I'm assuming all the socket.* options still apply if needed.

+1 vote

I'm trying to figure out how to get access to the cookies and headers passed up in the Websocket handshake request on Tomcat 8.

In Tomcat 7 the whole HttpServletRequest was passed into the WebSocketServlet. createWebSocketInbound method so it was easy to grab from the request headers. In Tomcat 8 the querystring and URI are both exposed by the javax.websocket.Session passed to ServerEndPoint.onOpen, but I don't see a mechanism for getting the cookies or headers.

We are integrating Websocket connections into an existing web app and want to use the cookies set by our web app in the Websocket connection process.

+1 vote

I'm trying to use the Tomcat8 jsr client functionality in a standalone java client. I'm trying to use the minimal number of jars, so I gabbed websocket-api.jar ONLY. When I call ContainerProvider.getWebSocketContainer(), it returns null. Do I need another jar to resolve this on the client?

...