Re: [hybi] Is it important to know frame length at the start of frame? (was: Re: Discontinuation of mux ...)

[Zhong Yu <[e-mail]>]

On Wed, Feb 12, 2014 at 10:25 AM, Peter Thorson <[e-mail]> wrote:
>
> On Feb 12, 2014, at 10:00, Zhong Yu <[e-mail]> wrote:
>
>> Why not send the message in one frame? The frame length is then the
>> message length.
>
> The message length might not be known or might not be fully buffer-able by the sending endpoint.
>
>> One argument for fragmentation is to insert control frames while
>> transmitting a long message. However that reasoning is not very
>> convincing:
>>
>> PONG - as long as we are writing data, any data, the peer should see
>> that the connection is alive. It's unreasonable for the peer to think
>> that our end is unresponsive while it is receiving data from us.
>>
>> PING - not necessary while we are writing data. If peer is
>> unresponsive, we'll learn that from TCP layer.
>
> It does provide some separation of concerns and the ability to do things like measure RTT during a long message.
>
>> CLOSE - closing the connection in the middle of a message is abnormal
>> anyway, it's probably not important to do the close handshake.
>
> It can be used to cleanly close a connection after a message has been sent but before it is completed. Say a client initiates a transfer then decides to leave halfway through (browser tab closes, etc). The client can indicate that it wants to close and that the in flight message should be discarded. Otherwise the client would have to either truncate the message (which might result in bogus data getting processed by the server) or just close the TCP connection (which can leave the connection in a bad state on the server and causes the server to have to report an unclean close to its application, which isn't entirely accurate).

I don't quite buy this argument. Browsers initial TCP FIN all the
time, to shutdown persistent HTTP connections for example.