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

[Andy Green <[e-mail]>]

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.

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 and ask it to send the CLOSE frame 
with Z_FULL_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.

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.

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

-Andy