On Wed, 2012-07-11 at 16:02 -0700, Scott Ferguson wrote:
> On 07/11/2012 01:59 AM, Mark Thomas wrote:
> > On 10/07/2012 23:07, Scott Ferguson wrote:
> >> On 07/10/2012 11:43 AM, Mark Thomas wrote:
> >>>
> >>> +1. This is what Tomcat currently does.
> >>>
> >>> However, the maximum frame size for WebSocket distorts things somewhat.
> >>> As much as I wish that the maximum frame size was much, much smaller, we
> >>> have to deal with the protocol we have. Therefore, it is somewhat
> >>> reluctantly that I think we have the ability to handle individual frames
> >>> in an async manner.
> >> I don't understand. The frame size doesn't matter for the receiver
> >> (unless you're implementing mux.) The frame size is not related to
> >> blocking/non-blocking.
> > 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.
>
> But the frame size itself is irrelevant to that issue. Consider a 1M
> message.
>
> 1. The client sends one big frame, but sends 1 byte TCP packets every 1 sec.
>
> 2. The clients sends 1M one byte frames, sending each frame in a TCP
> packet every 1 sec.
>
> There is zero difference between those scenarios wrt blocking/non-blocking.
Well, I don't agree with that. If frames were limited to 16bit, it would
be possible to fully buffer them inside the container (which internally
would be using async IO), and only notify the application once the frame
is complete. That would be the driving idea (and the API would be frame
based - meh - but much simpler, with no async IO, only notification of
inbound frames; writing would still need a small trick, but probably
limited to a canWrite flag and a notification like Servlet 3.1).
So instead, async probably has to be fully exposed, and the application
has to deal with partial frame content (guaranteed to never mean
anything) :(
Async here means "Servlet 3.1 async IO"-like, something allowing never
having to do a blocking read or write.
> >> 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.
>
> Frames are a red herring. The receiver does not care about frame size at
> all.
>
> What matters to the receiver is TCP packets, which have no intrinsic
> relation to the frames.
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc