On 11/07/2012 16:01, Remy Maucherat wrote:
> On Wed, 2012-07-11 at 09:59 +0100, Mark Thomas wrote:
>> That depends on how the client is (ab)using the protocol.
>>
>> If the client uses a very large frame size and sends data in drips and
>> drabs then you have to read the frame using non-blocking if you want the
>> server to be able to scale.
>>
>> One could argue that a client behaving in this manner is abusing the
>> protocol and the client should be sending multiple smaller frames where
>> the entire frame is sent. If we took that view, then non-blocking
>> between frames and blocking within a frame is reasonable solution. This
>> is still my favoured approach but I don't think it is a view that the
>> rest of the EG supports. I be very happy if I was wrong on that though.
>
> It's obvious people always abuse protocols and APIs. The source of the
> design problem here is that websocket allows unlimited frames [while
> everyone would have been very fine if frames were limited to only
> 16bit]. The argument is then that we should design the API for 16bit
> frames, and sacrifice scalability for the rest.
>
> Not convinced yet ... I am ok with fixing websockets though :)
Yep, that is my argument in a nutshell. I'd love to fix the protocol too
but I am not holding my breath on that one.
>>> It is important that the API can deliver partial frames to allow
>>> implementations with a small fixed buffer.
>>
>> I agree there needs to be a way for large messages to be consumed
>> without having to buffer the entire message. Given that there are a lot
>> of APIs that expect streams and that it is much easier to implement
>> chunking / partial frames (or whatever you want to call it) on top of a
>> stream than it is to implement streams on top of chunking / partial
>> frames then I think the underlying implementation should be streams with
>> (optionally) the partial frames implemented on top.
>
> But the Servlet API provides async IO underneath the websocket
> implementation, so that makes async the default target for the JSR API.
Fair point. I was coming at this from the direction of the current
Tomcat WebSocket implementation on top of Servlet 3.0. I need to spend
some time looking at how the current implementation might change when
running on Servlet 3.1
One point to keep in mind is that there are lots of folks that want
WebSocket now. Given the typical pace of adoption of new specification
versions, having something that could work on Servlet 3.0 (or possibly
even earlier) rather than requiring Servlet 3.1 is worth considering.
OK, HTTP upgrade isn't available but containers could provide a
container specific extension for that.
Mark