[hybi] change in 07: Payload only compression extension (was Re: With deflate-stream, Close frame doesn't work as an end of data marker)

(as co-chair I want to bring your attention to this)

Hi there,

the following changes (proposed by Takeshi Yoshino in [1])
has been largely discussed (for the technical reasons follow the 
discussions thread [1] and [2]):
the discussion has highlighted that the proposal brings some benefit and 
no side effects.

[1] http://www.ietf.org/mail-archive/web/hybi/current/msg06642.html
[2] http://www.ietf.org/mail-archive/web/hybi/current/msg06801.html
[3] http://www.ietf.org/mail-archive/web/hybi/current/msg06674.html

so unless anyone object strongly -07 will include the "yoshino-san's 
proposal" [3]

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

On 3/10/11 7:22 AM, Ian Fette (イアンフェッティ) wrote:
> I'm going over the threads trying to figure out what i need to do, and 
> I will admit that this one has me a bit stumped. If we adopt 
> yoshino-san's proposal [1] to only compress the payload of the frame, 
> does that put this issue to rest?
>
> [1] http://www.ietf.org/mail-archive/web/hybi/current/msg06674.html
>
> On Wed, Mar 9, 2011 at 2:13 PM, Andy Green <andy@warmcat.com 
> <mailto:andy@warmcat.com>> wrote:
>
>     On 03/09/2011 09:51 PM, Somebody in the thread at some point said:
>
>     Hi -
>
>         > 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.
>
>
>     It's a good point.  I can see how that's effectively fragmenting
>     the thing entirely in userland at the receiver.
>
>     However that seems simple to solve since the extra junk data is
>     already received in kernel.  Just before socket close time we just
>     need to use a little poll() POLLIN loop with no timeout to drain
>     it while there's stuff immediately pending, right?  Nothing more
>     will come and close is always happy.
>
>
>     -Andy
>     _______________________________________________
>     hybi mailing list
>     hybi@ietf.org <mailto:hybi@ietf.org>
>     https://www.ietf.org/mailman/listinfo/hybi
>
>