Re: [hybi] frame length encoding

[Brian <[e-mail]>]

Hey all!  I've been watching this list for two or three weeks now, and
decided to finally chime in.

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 --
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.  I don't want to be bound to treat absurdly large frames as
potentially legitimate by an overzealous specification.  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.  I *can't*
correctly handle a 63-bit frame.  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....

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.  This
is not and should not be an all-things to all-people protocol.  We shouldn't
be designing for these edge cases just because the protocol could
theoretically enable any number of diverse applications.

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.  It's meant exclusively for
communicating with JavaScript-based applications running in a web browser.
 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.


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.  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.


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.  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. :-)


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
>