Re: [hybi] frame length encoding

[Roberto Peon <[e-mail]>]

On Sun, Aug 22, 2010 at 1:42 AM, Shelby Moore <[e-mail]> wrote:

> > On Sat, Aug 21, 2010 at 8:23 PM, Shelby Moore <[e-mail]>
> wrote:
> >
> >> > On Sat, 2010-08-21 at 16:59 -0400, John Tamplin wrote:
> >> >> On Sat, Aug 21, 2010 at 4:57 PM, Shelby Moore <[e-mail]>
> >> >> wrote:
> >> >
> >> >>          Can you simply rewrite
> >> >>         one sector on disk and the memory manager remaps?
> >> >>
> >> >>
> >> >> I haven't tried it personally, but I would suspect you could use
> >> >> TCP_CORK, write a header, use sendfile to send a chunk of the file to
> >> >> finish the frame, uncork, repeat until done.  I don't think there
> >> >> would be any extra copying involved here, but you can't just issue
> >> the
> >> >> sendfile and go on to the next message, you need some thread that
> >> will
> >> >> queue up the next frame when it is ready.
> >> >
> >> > That is correct (and I have done this personally), you need multiple
> >> > calls of the ZC API interleaved with the write of the chunk header.
> >> > There is no copying of the data through the CPU just because it
> >> requires
> >> > multiple calls. And there is no reason you couldn't implement some
> >> kind
> >> > of writev() like API that lets you interleave copied and zero-copied
> >> > data.
> >> >
> >> > And yes, multiple calls are more overhead than 1 call. but at 1 per
> >> 4GB,
> >> > it really is inconsequential.
> >>
> >> That is an extremely technical solution applicable to experienced
> >> sysadmins.
> >>
> >> But WebSockets is supposed to be used also by web programming amateurs.
> >> It is much easier for them to issue a single sendFile() call from PHP,
> >> Perl, Ruby, etc., without all the fuss and low-level network stack API
> >> synchronization.
> >>
> >
> > No, that (amateur programmers) is not a requirement currently as I
> > understand things.
> > The expectation is that we develop the minimal featureset necessary to
> > ensure a robust and hopefully efficient transport.
> > There are different perspectives about what that featureset need be
> > assuming
> > competent professional programmers, and that is how you should be looking
> > it
> > it!
> > -=R
>
> My understanding is that the "amateur programmers" requirement was only
> removed for those who process the protocol directly, not for those who use
> WS in scripting applications such as Javascript in browser, PHP, Perl, etc
> on server. Am I incorrect?
>

The API should be easily used and there should be trivial applications which
may use it.
I don't believe there is any requirement for this which has been explicitly
stated, but there have been concerns voiced about the feasibility of
representing various data in JS. I believe that consensus was reached on
binary/utf representation of data as a result of these concerns.

Which is a long-winded way of saying that you're correct that protocol
implementors (servers, browsers, intermediaries) had the "amateur
programmer" requirement lifted.


>
> I would strongly disagree if we go against "amateur programming" in
> scripting uses of WS.  I do agree with the elimination of "amateur
> programming" requirement for protocol implementation programmers.
>

Excellent, then I think that matches what I perceived as the stated
consensus.

-=R