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 :)
> > 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.
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc