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

Hi Takeshi,

Good point. There is indeed a legitmate case where trailing bytes is 
present after 
Close frame.

It is important to note that after endpoint sent and received Close frame, 
it is considered 
that WebSocket layer close handshake has been complete ('wasClear' gets 
set to 1, 
etc.).

What Takeshi pointed out is a good motivation for WS-layer to perform 
graceful 
shutdown at TCP layer as well. After Close frame has been exchanged 
successfully, 
the endpoint must start shutting down the local TCP connection with 
shutdown(SHUT_WR), and discard the trailing bytes, if any received, and 
then finally 
close the socket on receipt of EoS.

This works for any trailing bytes that could be caused by artifact of 
another deflate 
algorithm that may be introduced in the future, or just by a bug.

- Yutaka

hybi-bounces@ietf.org wrote on 02/16/2011 06:20:18 PM:

> It's still under discussion if it's really necessary (see "Clarify 
> the role of closing handshake" thread), but RST suppression was one 
> of the original objectives of Close frame. Close frame assures no 
> more data is coming on the underlying channel to allow the endpoint 
> to close(2) safely.
> 
> deflate-stream extension in -05 applies deflate on whole octets of a
> frame including the header. If we simply use zlib's flush, we can 
> spoil this function of Close frame. There can be some data remain 
> not processed/recv-ed even after getting a Close frame uncompressed.
> 
> e.g.
> (if Z_SYNC_FLUSH is used) possibly a few octets containing EoB 
> symbol, 3-bit header, padding, and then BTYPE=00 block "00 00 ff ff".
> (if Z_FINISH is used) possibly one octet containing EoB symbol.
> 
> Endpoints need to drain these octets to prevent RST. This should be 
noted.
> 
> Takeshi_______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi