Re: [hybi] Framing Take VI (a compromise proposal)

[Takeshi Yoshino <[e-mail]>]

2010年8月14日14:47 Takeshi Yoshino <[e-mail]>:

> 2010年8月14日6:20 Ian Fette (イアンフェッティ) <[e-mail]>:
>
> On Fri, Aug 13, 2010 at 2:16 PM, Ian Hickson <[e-mail]> wrote:
>>
>>> 2010/8/12 Ian Fette (イアンフェッティ) <[e-mail]>:
>>> >
>>> > That said, here's the proposal:
>>>
>>> This seems overly complex. In particular:
>>>
>>>  - I don't see the need for explicit extension lengths.
>>>
>>>
>> If you don't want to use any extensions, which I assume you don't, then
>> set EXT=0 and you don't have to set any extension lengths. Given that you
>> don't seem to want to use extensions, I'm not sure why you seem to have a
>> preference for how extension data is stated.
>>
>>
>>>  - I don't see what having both a short length and a long length gets
>>> us. Saving 7 bytes seems like a very minimal gain, especially when
>>> considered in the context of the rest of the header and the IP and TCP
>>> overhead.
>>>
>>>
>> An alternate would be to use a variable length. I really don't care that
>> much.
>>
>>
>
> I don't have strong preference on this point, too.
>
> But let me provide some metric about this. As you said, people who mind
> latency much would turn off NAGLE, so short packets containing, e.g. key
> stroke of 1 octet would ultimately forms minimum_gap(8) + ethernet(18) +
> ipv4(20) + tcp(20) + type(1) + len(1) + payload(1) = 69 octet on wire.
> difference of 7 octets is just 10% increase on wire and
>

Pardon me. minimum_gap 8 -> 12 (most modern NICs work with 8, i think, but
takes number on the 802.3). And, I missed preamble, so s/69 octet/81 octet/.
7/81=8.64% increase on occupation on ethernet baseband signal.

Takeshi


> 7/43=16% increase on kernel level, and 3/9=33% increase on WebSocket level.
> Not much as 33%, 16% and 10% still seems not so negligible amount.
>
> If a user sends short messages and doesn't urge so much the messages to be
> delivered, client can be implemented using some buffering so that they
> (multiple WebSocket frames for multiple send() calls) can be combined into
> one TCP packet. In such case, the difference of length header size would be
> more significant. Actually, this can be also solved on application level by
> combining e.g. several key stroke information into one send() call, so it's
> not strong support for this choice.
>
> Takeshi
>
>
>>  - Supporting fragmentation today is premature. We have no experience
>>> with how people use this protocol, we shouldn't be adding such
>>> features yet. Six months from now, sure, once we can quantify what it
>>> is people actually need.
>>>
>>>
>> This point has been argued extensively enough on the list that I don't
>> think anything I say here is going to be new.
>>
>>
>>>  - I don't see why we would need to flag fragmentation frames using
>>> reserved bits rather than just using the frame type byte mechanic.
>>> Just define four frame types for text and four frame types for binary
>>> when we add binary (not fragmented, fragment start, fragment middle,
>>> fragment end).
>>>
>>> --
>>> Ian Hickson
>>>
>>
>>
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>>
>