Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker

[Takeshi Yoshino <[e-mail]>]

On Wed, Mar 9, 2011 at 23:31, Andy Green <[e-mail]> wrote:

> On 03/09/2011 02:02 PM, Somebody in the thread at some point said:
>
> Hi -
>
>  I'm still not sure if we're on the same table. Please allow me to
>> explain my thoughts again. Sorry if i'm misunderstanding your point.
>>
>> Sending a close frame is not a problem. What I'm taking as a (small,
>>
>
> OK.
>
>
>  but) problem is receiving a close frame. "Trailing bytes after Close
>> frame" in Yutaka's post doesn't mean "any further packet" or "any other
>> traffic going" on the WebSocket layer. It means trailing bytes generated
>> by zlib.
>>
>> Your code luckily drained the "close, 3 bit header, 00 00 ff ff" which
>> contains octets generated by zlib for performing Z_FULL_FLUSH. But
>> please imagine someone split them into two TCP packets e.g. "close
>> codes, 3 bit header" and "00 00 ff ff" and inserted some delay between
>>
>
> OK.
>
>
>  them. Your callback is run with eff_buf.token filled with "... close
>> codes, 3 bit header", and after that your callback is run again with
>> eff_buf.token = "00 00 ff ff".
>>
>
> OK I think I get your idea.  So it is possible at the receiver I get enough
> zlib codes in one packet that it emits the full close frame decompressed
> from inflate(), and I go off and interpret that and try to close the socket,
> but there is already some "dribble" from zlib in flight in a second packet
> which never gets serviced then.
>
Yes!


>
> The only thing is I set it to do Z_PARTIAL_FLUSH after every input is added
> to the compressor.  So it means the compressor cannot be holding much of
> anything at the time we come


I'm doing the same in pywebsocket (using Z_SYNC_FLUSH).


> and ask it to send the CLOSE frame with Z_FULL_FLUSH.


Yes, too (Z_SYNC_FLUSH).


>  CLOSE frame is limited to 125 payload.  So it seems it would always issue
> one final compressed output buffer in this case, including zlib trailer,
> which translates to one packet on the wire reliably.  I'm also using
> TCP_NODELAY to stop it aggregating packets and causing latency.
>
It makes sense.


>
> I agree it is a theoretical opportunity for something else to fragment the
> packet and make the situation you're describing, but I can't see it
> happening the thing is on a link with like 30-40 byte MTU which is what is
> needed including TCP /IP headers to break the packet there.
>
> Yes. Because of that, I'm not so eager to push this idea... But if we can
have better one, I think it's nice.

One method I can come up with
- by which we can make sure that we recv all the data zlib emit
- that can be applied to stream-based deflate
is putting BFINAL=1 block at the end of stream. zlib does this when Z_FINISH
is specified. That block contains full or some portion of close frame octets
or even empty one after close codes is ok. zlib returns EoF by some manner
when it consumed all the data terminated by BFINAL=1 block.

python's zlib wrapper doesn't have API to probe EoF now, so I can't apply
this to pywebsocket, but it seems it's applicable on many environment
(original C zlib, Java, etc.)


> Are there other circumstances that can actually cause this I'm overlooking
> too easily?  Thanks for explaining your meaning to me.
>
No problem. Thanks.


>
> -Andy
>