On 26/01/2013 01:10, Danny Coward wrote:
On 1/24/13 5:00 AM, Mark Thomas wrote:This does raise the separate question of message vs. fragment. I think
Hi,Well, its probably reasonable to implement that maximum on frame sizes,
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
Therefore, I'd like to prose that the buffer sizes are defined as ints
rather than longs.
but on the other hand since the message size is not limited by the spec,
we probably should use the larger capacity to define the limit. Someone
might want it one day !
the specification and the Javadoc need to draw much clear distinctions
between the two. I think in most places wee use message we should
probably be using fragment.
Getting back to the original question, I still don't see a way of
sending a fragment larger than Integer.MAX_VALUE through the API except
through a Writer or OutputStream and even then buffering the content (as
the size has to be known before the fragment can be sent) for fragments
larger than Integer.MAX_VALUE is going to be a challenge.
Is it not reasonable to limit fragment sizes supported by this API to
[jsr356-experts] Re: [jsr356-users] Buffer sizes