Skip to main content

[jsr356-experts] Re: [jsr356-users] Buffer sizes

  • From: Scott Ferguson < >
  • To:
  • Subject: [jsr356-experts] Re: [jsr356-users] Buffer sizes
  • Date: Mon, 28 Jan 2013 16:16:40 -0800

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




[jsr356-experts] Buffer sizes

Mark Thomas 01/24/2013

[jsr356-experts] Re: [jsr356-users] Buffer sizes

Danny Coward 01/26/2013

[jsr356-experts] Re: [jsr356-users] Buffer sizes

Mark Thomas 01/28/2013

[jsr356-experts] Re: [jsr356-users] Buffer sizes

Scott Ferguson 01/29/2013

[jsr356-experts] Re: [jsr356-users] Buffer sizes

Mark Thomas 01/29/2013

[jsr356-experts] Re: [jsr356-users] Buffer sizes

Scott Ferguson 01/29/2013

[jsr356-experts] Re: [jsr356-users] Buffer sizes

Mark Thomas 01/30/2013

[jsr356-experts] Re: [jsr356-users] Buffer sizes

Bill Wigger 01/30/2013
 
 
Close
loading
Please Confirm
Close