Re: [hybi] Flow control quota

[Takeshi Yoshino <[e-mail]>]

On Fri, Jun 8, 2012 at 8:06 PM, Arman Djusupov <[e-mail]> wrote:

> By ignoring the RSV bits we don't resolve the problem of compressed frames
> being unfragmentable. Even if the compression flag was in the payload it
> would still not allow us to reassemble a compressed frame once it was
> fragmented. Since a compressed frame has its final 4 bytes stripped off,
> the
> receiver needs to know the frame boundary prior to its fragmentation in
> order to append the final 4 bytes at the proper place.
>

Yes. Current per-frame compression extensions is using both frame boundary
information and RSV1 bit.

I took this way to make it easy to flush a part of a message with 4 byte
optimization on most platforms. Thinking again, this optimization is very
useful only for small messages. To flush a part of a big message, this
optimization would be negligible.

IIRC, there's nothing so important that prevents us from changing it from
per-frame to per-message. Per-message spec would allow users to concatenate
SYNC_FLUSH-ed chunks, remove the 4 byte at the end of the message, split
the resulting string at arbitrary point to generate fragments and send
them. We may use only the RSV1 on the first fragment of the message.


> We could perform a compression flush at the end of the message boundary
> rather than on each frame. In this case the final frame of the message
> would
> indicate the end of the self-contained compressed chunk and every frame
> would be fragmentable. This is actually more in tune with the WS spec where
> each frame is not required to  contain interpretable data. But as far as
> the
> mux extension is concerned this would still be just a workaround since
> there
> might be other frame-level extensions that require the frame to be
> preserved.
>

It's also an option that we give up frame-level extensions other than mux.


> At the same time Jamie's solution to allow mux to envelope and fragment all
> frames on the wire also pushes the problem to the next layer. When
> compression would be used with mux, the receiving side would have to buffer
> and assemble the fragments of the frame prior to decompressing it. So, on
> one side, the mux flow control algorithm would consider the data as
> received
> and would send the quota to the remote side. At the same time,  the frame
> being received would have to be buffered while its final chunk is still on
>

At least, deflate can be processed progressively as each frame arrives even
if the spec is modified to be per-message as described above. Let's just
give up use of the core WebSocket frame boundary to pass the unit of
compression (or any other feature). Let's use some compression-specific
framing inside message body if necessary. RSV bits are still available but
would be message-wise feature. What do you think?

Compression after mux still need to be per-frame basis.


> the wire. So an intermediary or server performing decompression would have
> to be smart enough to decompress and forward whatever possible, buffering
> only the final part of frame that it is still impossible to decompress.
>