On 26/01/2013 01:10, Danny Coward wrote:
> On 1/24/13 5:00 AM, Mark Thomas 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.
> Well, its probably reasonable to implement that maximum on frame sizes,
> 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 !
This does raise the separate question of message vs. fragment. I think
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
Integer.MAX_VALUE?
Mark