On 29/01/2013 15:53, Scott Ferguson wrote:
> On 1/29/13 1:42 AM, Mark Thomas wrote:
>> On 29/01/2013 00:16, Scott Ferguson wrote:
>>>
>>> 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.
>
> Those callbacks are not necessarily IETF 6455 fragments.
Then the JSR 356 specification and Javadoc need to be clarified. If
RFC6455 talks about messages and fragments and JSR 356 that implements
RFC 6455 talks about messages and fragments then it is a reasonable
assumption that they are talking about the same things. If that is not
that case then the JSR 356 either needs a very, very clear clarification
or better some different terminology. "Messages" and "partial messages"
would be fine with me along with some text that made clear "JSR 356
partial message" != "RFC6455 fragment".
>>> 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.
>
> There's no point of specifying buffer sizes on outgoing messages,
> because the implementation
> could choose to use a fixed 256 byte buffer if it wished.
If outgoing buffer sizes were configurable, the implementation wouldn't
be able to use a fixed buffer size.
If batching is used then there is likely to be a desire to control the
outgoing buffer size.
To get back to my original point (which isn't the merits or not of
controlling the outgoing buffer size) if the specification intends that
the buffer size only applies to incoming messages then that 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.
>
> Nope. Protocols like TCP and WebSockets and HTTP don't make their
> internal fragmentation visible to applications for good reasons.
I don't disagree with you on that point but my comment about about the
use of language in the JSR 356 spec stands.
>>> 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?
<snip/>
>> It doesn't make sense to put limits on the length of a message because
>> RFC6455 does not put any limits on message length.
> Well, technically true, but a 2^63 long isn't a limit in any practical
> sense.
<snip/>
> The limits are for DOS issues.
>
> The 2^63 limit was specifically for sendfile. There are files larger
> than 2G. The current draft doesn't
> have a sendfile call, but a future one could.
>
> long isn't a practical limit because it's not possible to send 2^63 bytes.
I'm not sure if you are agreeing with me here or not.
If the limits are intended only for incoming messages (which I have no
issue with but raises the question of how to set a limit for batching
outgoing messages) and messages are going to be passed to applications
as byte[], ByteBuffer or String then the limits needs to be set using
int not long simply because of the maximum size of those objects. There
is no point allowing a user to set a limit above Integer.MAX_VALUE as
the implementation will just fall over trying to create a buffer that big.
Mark