Re: [hybi] Max frame size

["Andy Green (林安廸)" <[e-mail]>]

On 06/23/2011 12:01 PM, Somebody in the thread at some point said:

> While I see this API makes the buffering (max frame size) problem for
> the websocket developer to be not an issue, is in fact not solving but
> moving the problem to the app level where, again, the application will
> have to buffer the content until a message is completed.
>
> I still think we need a way to each party to notify its buffering or
> message size limit capabilities, *mainly*, because we have a framing
> designed to notify messages, defined as *units* by the draft, not
> bytes...

The way I think of it is that frames are directly analogous to TCP/IP 
packets, one level up.

Everyone accepts application code has to act defensively and not make 
assumptions about tcp / ip packet lengths and if they got merged or 
fragmented along the way.  How much turns up at any given time when 
poll() or select() tells you something came must be treated like a 
random number you find out when you read from the socket and it says how 
much was ready.  You can't be expecting 32 bytes every time because you 
think that the sender always sends 32 byte packets.

It's the same with frames, reliance on assumptions about when they turn 
up, in how many pieces of what size needs to be defended against in the 
code so it's not vulnerable to problems.  If you take that approach it 
naturally leads you away from this idea you need to buffer whole frames.

-Andy