Re: [hybi] frame length encoding

["Shelby Moore" <[e-mail]>]

Hi Brian,

Although I do appreciate your sentiments and also appreciate John and
others for trying to move towards concensus, I have some feedback to you.


> As much as I feel that 63-bits is ridiculously large for the frame length,
> I'd be happy to accept it and just move on to the next item of discussion
> --

Noted.

> though the WS server I'm writing right now will consider any frame with a
> non-zero bit in the high 31-bits of the long long length field to be an
> error condition, and immediately drop the rogue/attacking/misbehaving
> client.

64-bit computing is rogue? I thought it was a desired advancement.

>  I don't want to be bound to treat absurdly large frames as
> potentially legitimate by an overzealous specification.

You do not want to ever be bound to moving to 64-bit computing?

And if you do one day accept the need to move to 64-bit computing, how
difficult will it be to come back and redo WS and get the new version
adopted in reasonable time?

I say the push to 64-bit is now and we are derelict in our duties if
release a new protocol that is looking backwards about 2 decades.  I
relented on my 128-bit suggestion.

>  Furthermore, I'm
> writing my server with Node.js, which, being a JavaScript-based
> environment
> itself, doesn't even have a 64-bit integer type of any sort.

Javascript will never support 64-bit?

In meantime, WS browser code can do the re-fragmentation, you will never
see larger than 32-bit frame in Javascript, until that browser's
Javascript is 64-bit.


>  I *can't*
> correctly handle a 63-bit frame.

Yes you can. See above.

>  Ah, the irony of a protocol meant for
> JavaScript applications that's impossible to fully implemented in
> JavaScript
> (at least efficiently -- no bignum libraries allowed.)  And who knows what
> would happen with the actual frame data in, say, a JavaScript String, with
> a
> frame of a few terabytes?  Assuming anyone had that much RAM?   We're
> talking about JavaScript clients here, so no streaming to disk, etc....


Again see above, you will never have to store something that Javascript
can't store.

> In my not-so-humble opinion, trying to accommodate sending large files
> through WebSockets is a complete and utter misdirection.  The protocol
> exists to provide real-time interactivity support to browsers.  That's
> what
> it's meant for.  If someone wants to send large chunks of data (>4GB) in
> one
> frame, they should find another protocol, because they're clearly not
> planning to process it in JavaScript in a web-browser client.  And if
> they're not running in the browser, there's no reason they have to use WS.
>  Making abusers of the protocol chunk at 4GB boundaries is more than
> reasonable when you consider that the vast majority of users won't begin
> to
> consider sending fragments anywhere near even a fraction of that size.

I deduce/conjecture that WS will also be used to replace Flash in HTML5,
so that users can get video streaming without a plugin or Flash server
license. And I think we also need to consider the amateur webserver
programmers who simply want to dump a sendFile() of their DVD to client
who can display it.  We don't want to limit the simple optimization (DMA
-> NIC, no CPU load) that capability to sysadmins who understand low-level
TCP tricks.  It doesn't cost you anything on the intermediary or client
side, as we have to support re-fragmentation (and/or negotiation on
handshake) any way (because no matter what maximum size we choose, not all
intermediaries will necessarily support it).

> This
> is not and should not be an all-things to all-people protocol.

Why not?

>  We
> shouldn't
> be designing for these edge cases just because the protocol could
> theoretically enable any number of diverse applications.

Web video is going to be edge case?  I don't think so!  It may end up
being the majority of the traffic (if measured in bytes, not frames) for
WS.

> Lets get back to basics!  WebSockets was conceived to provide super-simple
> bi-directional persistent communications on a platform -- the browser --
> that had no such pre-existing canonical ability.

What is not simple that could be designed away from our frame header?

>  It's meant exclusively
> for
> communicating with JavaScript-based applications running in a web browser.

Disagree as noted above.

>  WebSockets may end up being used or abused for other things, but that is
> not the intended purpose and, in my opinion, such uses shouldn't be the
> concern of this working group.

Web video is an abuse of WS?

> Pedantic discussion of details and attempting to figure out how to
> accomodate theoretical (ab)uses of this protocol has become a very real
> distraction to the group.  The volume of mail generated by this list has
> skyrocketed in the last week or so and most of the content can really be
> summed up as quibbling over minutia.

Disagree with that "quibbling over minutia" characterization.  I showed
that for the bi-direction events you are batting for, that "minutia" could
cause a doubling of network traffic in the extreme case.

Good design is a lot of work.

>  Let's pick a reasonable solution and
> move forward, even if a tiny subset of people who want to abuse WS for
> something outside the browser don't like it.

Agreed!  But I think the abusers are the ones who argue they can't check
one bit in the header and switch to 64-bit processing.

>
>
> For the record, my vote for frame size encoding goes to John's
> original option #2.  It's simple, clean, easy, and efficient.  The only
> change I'd make is to go to a 32-bit maximum, but I'm happy to accept a
> 63-bit field in the spec if it means we can move on.


Noted.  I am obviously arguing for the 63-bit field.


>  Also, thank you,
> John,
> for taking the time to attempt to steer this issue to consensus!  It's
> hard
> to keep up with the current theoretical consensus of where the spec is
> going
> with all the pedantry on the list at the moment.
>
> As for the concern about keeping a sufficient number of reserved bits...
> throw in a whole reserved byte and put a bow on it. :-)

That might not be a bad idea.  But I think we will know that more as we
move forward on designed the extensions?

1 byte is not that ridiculous, because we already have 3 bytes minimum
including a 1 byte payload.

>
>
> Cheers,
> Brian McKelvey
>
>
>
>
> On Sat, Aug 21, 2010 at 5:00 PM, Patrick McManus
> <[e-mail]>wrote:
>
>> On Sat, 2010-08-21 at 17:25 -0400, Shelby Moore wrote:
>> > [snip]
>> >
>> > > 32 bits with chunking would be fine to accommodate zero copy.
>> > >
>> > > there are some folks that want to be able to send any message in one
>> > > chunk for unrelated reasons.
>> >
>> > How can they send in one chunk if their file size is greater than 32
>> bit
>> > length, if you limit the size to 32bit?
>>
>> I did not say they could fit 33 bits of stuff in a 32 bit bucket.
>>
>> I said that some folks want a >32 bit chunk size for reasons unrelated
>> to zero copying performance.
>>
>>
>>
>>
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>