Re: [hybi] Technical feedback. was: Process!

[Jamie Lokier <[e-mail]>]

Justin Erenkrantz wrote:
> On Mon, Feb 1, 2010 at 3:48 PM, Ian Hickson <[e-mail]> wrote:
> > On Fri, 29 Jan 2010, Justin Erenkrantz wrote:
> >>
> >> Again, this is why the current draft is so impenetrable (to me) since it
> >> expects that the only person implementing the draft is a client vendor
> >> using synchronous socket methods...which sort of defeats the purpose
> >> when you are trying to write a fully async client...or any type of
> >> server.
> >
> > Could you elaborate on this? I looked for text that assumed synchronous
> > socket methods but couldn't find any. Could you quote the offending text?
> 
> All of them are...such as:
> 
> ---
>           Run these steps.  If at any point during these steps a read is
>           attempted but fails because the Web Socket connection is
>           closed, then abort.
> 
>           1.  Let /length/ be zero.
> 
>           2.  _Length_: Read a byte, let /b/ be that byte.
> 
>           3.  Let /b_v/ be integer corresponding to the low 7 bits of
>               /b/ (the value you would get by _and_ing /b/ with 0x7F).
> 
>           4.  Multiply /length/ by 128, add /b_v/ to that result, and
>               store the final result in /length/.
> 
>           5.  If the high-order bit of /b/ is set (i.e. if /b/ _and_ed
>               with 0x80 returns 0x80), then return to the step above
>               labeled _length_.
> 
>           6.  Read /length/ bytes.
> 
>           7.  Discard the read bytes.
> ---
> 
> Greg pointed out issues as to what "send" or "receive" means -
> buffering, etc, etc.
> 
> The algorithmic descriptions can only be precisely followed when you
> write a synchronous client (or server) - the algorithms for an network
> async read or write framework would appear hugely different.  Again, I
> think this challenges the usefulness of specifying the protocol in
> pseudo-code when many (optimized?) implementations won't be able to
> follow those same algorithms.  -- justin

To be honest, I don't see a big problem with the draft in this area.

But perhaps I already have a clear idea how I would implement it and
it's not clear to someone doing it from scratch.

You just have to assume there are buffers.  "send" means queuing bytes
in your output buffer (it's up to the implementation when it actually
sends them), and "receive" means reading them from your input buffer
(they will be read in blocks, no doubt).  "is closed" means "if
you read EOF at this point in the stream", not "is closed" :-)

There is no other meaningful way to interpret it.

Maybe it just needs to say the implementation can use buffering, and
everywhere in the document which mentions reading and writing, it can
be reading and writing the buffers.

Looking at the above, it would be quite a bit clearer to talk about
reading the end of the input (EOF, TCP FIN) than "if the connection is
closed", as the latter has several ambiguous meanings, and you don't
actually want to abort parsing when you know the socket is closed, if
you still have bytes to read from your buffer

-- Jamie