On 29/01/2013 00:16, Scott Ferguson wrote:
> 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.
Fragments are visible to the application. The Javadoc for
MessageHandler.Async<T> makes clear that the partial messages are 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.
I don't see anything in the Javadoc or the specification document that
states that the limit only applies to incoming messages. If that was the
intention, it needs to be made clear.
>> Is it not reasonable to limit fragment sizes supported by this API to
>> Integer.MAX_VALUE?
>
> Again, fragments are not visible to this API.
Again, they are.
> What would be the value of using an int instead of a long? It doesn't
> save memory or affect performance.
My point is that there is no way to pass a String, byte[] or ByteBuffer
longer than Integer.MAX_VALUE so why even allow the limit to be set
above that?
It doesn't make sense to put limits on the length of a message because
RFC6455 does not put any limits on message length. The limit in RFC6455
is on fragment size which is 2^63-1 (Long.MAX_VALUE). While my
preference would be to use the limit from RFC6455 I don't believe it is
practical to do so in a Java implementation. The practical limit is
Integer.MAX_VALUE.
Mark