RFC 6455 <
https://tools.ietf.org/html/rfc6455> has no limits on Message
size.
It does however have limits on what a single Frame can be (a Message being
1..n frames)
According to the Section 5.2<
https://tools.ietf.org/html/rfc6455#section-5.2>:
Payload length, a Frame can be 71 bits (7+64 bits) in length.
So that means each Frame can be a maximum of 2,361,183,241,434,822,606,848
bytes in length.
--
Joakim Erdfelt <joakim_at_intalio.com>
webtide.com <http://www.webtide.com/>
Developer advice, services and support
from the Jetty & CometD experts
eclipse.org/jetty - cometd.org
On Thu, Jan 24, 2013 at 6:00 AM, Mark Thomas <mark_at_homeinbox.net> wrote:
> Hi,
>
> Currently WebSocketContainer defines buffer sizes using longs. I suspect
> that this is to be consistent with the maximum message size defined by
> RFC6455. Is a long here really realistic? The only way I can see of
> sending a message of that size through our API is with a Writer or an
> OutputStream. In those cases fragmenting at Integer.MAX_VALUE does not
> seem unreasonable.
>
> Therefore, I'd like to prose that the buffer sizes are defined as ints
> rather than longs.
>
> Thoughts?
>
> Mark
>