On 1/28/13 3:23 PM, Mark Thomas wrote:
> 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.
Fragments are not visible to the application. The Javadoc should never
refer to fragments.
>
> 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.
Since applications don't send fragments, this doesn't make much sense.
The limits in Session and WebSocketContainer are for incoming messages,
not outgoing messages.
>
> Is it not reasonable to limit fragment sizes supported by this API to
> Integer.MAX_VALUE?
Again, fragments are not visible to this API.
What would be the value of using an int instead of a long? It doesn't
save memory or affect performance.
-- Scott