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.
>> 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.
-- Scott