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

> 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?

Yes. Since your receive buffer passed in recv(2) has a predetermined 
finite size and you may not be reading all data in the kernel space 
(TCP) buffer. Depending on how it is implemented and timing, the
receiver may successfully extract Close frame out of data you have just
read from TCP socket, and then close the socket without bothering to 
read the outstanding data in the kernel.

- Yutaka

>  Thanks for explaining your meaning to me.
> 
> -Andy
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi