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

seems straight forward enough.

-ian

On Wed, Mar 9, 2011 at 10:59 PM, Salvatore Loreto <
salvatore.loreto@ericsson.com> wrote:

>  (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 Loretowww.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> 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
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>
>
>
>