On 18/09/2013 06:19, Igor Urisman wrote:
> Dear All,
> 
> 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.

>  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?

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.
> 
> 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?

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

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to