Subject: [hybi] sample implementation of my most recent proposal posted

From: John Tamplin <[email-masked]>
Date: Mon, 30 Aug 2010 21:07:08 -0400

I have written a sample implementation of my most recent proposal
(including the metadata extension part) and made it publicly available
at  -- note that this is not intended to be a reference implementation
or even one that would be recommended (I spent very little time
thinking about the API, so when real use-cases are developed it would
likely need to change).  Instead, it was an exercise to see if there
were any implementation gotchas and to see how simple a simple
implementation could be.  It turns out there is one gotcha I ran into
-- the extension data needs to be fragmentable since it could be
arbitrarily long, but that leads to some implementation complexities
that I did not address in this sample code.  Instead of requiring
support for fragmenting extension data, we could instead mandate
maximum extension data sizes, allow individual extension data items to
be spread to different fragments, and require that all intermediaries
support a particular minimum frame size (which would be sufficient to
hold the header and one maximum-length extension data block).  There
is also a bit of awkwardness regarding per-message metadata and
per-frame metadata.

I don't think we need to address these now, as we can debate the
various options when we get to designing extensions, but I wanted to
see if there was anything that *would* have to be discussed now.

   Proposal:  https://docs1.google.com/a/google.com/document/edit?id=1DIeJM-tRfJskE2-U3B7er2StU__1JqQsQg-lZC9UvY0&hl=en&authkey=CLStzbkI#
   Code:       http://code.google.com/p/websocket-draft-eval/

Before critiquing the code, please remember the purpose was not to
write the most efficient implementation or the most extensible one,
but a straightforward one that was clear and easy to understand.

--
John A. Tamplin
Software Engineer (GWT), Google

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 31 Aug 2010 12:18:00 +1000

On 31 August 2010 11:07, John Tamplin <[email-masked]> wrote:
> at

Good work!

> is also a bit of awkwardness regarding per-message metadata and

I think we want to explicitly say that extension data is not
fragmentable as I think it is
more than awkwardness to try to fragment per-frame metadata.

Are there any known use-cases that need large extension data?  So far
all the examples have been short strings, IDs and numbers.
The kind of thing that fits into a HTTP header, which are commonly
limited to 4k.

> Before critiquing the code...

That Utf8StringBuilder class is complete rubbish!!!!  Oh I wrote it :)

cheers

---

From: John Tamplin <[email-masked]>
Date: Mon, 30 Aug 2010 22:23:17 -0400

> The kind of thing that fits into a HTTP header, which are commonly

Until we actually get extensions implemented, it seems hard to
discount the value of having large metadata associated with it.  Even
if you say 4k is ok, then what happens when there are 10 extensions?
Do we want to require a MUX extension, for example, to keep a minimum
40k frame size?

Anyway, I wasn't trying to bring this problem up to be solved now,
mostly I was just saying that extensions vs fragmentation was the only
issue I saw while trying to implement it, and that it looks like that
can be totally handled (whichever way we want to handle it) when we
get around to defining how extensions work.

---

From: Hector Santos <[email-masked]>
Date: Mon, 30 Aug 2010 22:49:23 -0400

John,

Does it make sense to test the two extremes for simulating, emulating 
design and performance:

   - single byte I/O, i.e. Key Stroke Sensing
   - streaming I/O, i.e. multi-media.

I would like to see a test bed to test/measure the two extremes over 
this framing proposal.

Related and regarding extensions:

This goes back to a statement you made regarding "real-world" 
applications for websockets.

What are these real-world applications?

What comes to me is how we can leverage "raw" websockets adding the 
"extensions" to repeat methods already in place but now using websockets.

For example, interactive I/O notifications is an immediate benefit, 
thats pretty much a given everyone can see.

But beyond that, it will be server-driven.  Are these extensions JS 
code, browser plug-ins?

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: John Tamplin <[email-masked]>
Date: Mon, 30 Aug 2010 23:12:06 -0400

On Mon, Aug 30, 2010 at 10:49 PM, Hector Santos <[email-masked]> wrote:
> Does it make sense to test the two extremes for simulating, emulating design
> and performance:
>
> I would like to see a test bed to test/measure the two extremes over this
> framing proposal.

I'm not sure measuring performance with a proof of concept
implementation is likely to be worth the effort.  In reality, I would
expect the implementation to be closely tied to existing network
infrastructure in the server and client.  For example, Jetty would
likely make use of the IO subsystem already in place, so trying to
measure something built from scratch like this example would not give
representative performance, and trying to replicate all of Jetty's IO
layer would be a waste of time.  I think it would be better, once we
get agreement on the base framing protocol, to actually get an
implementation in real-world clients and servers and see how it works.

For multi-media streaming, it seems unlikely that would be supported
in browsers anytime soon given the JS API and the limited ability JS
would have to get the data to the player, so it would likely be
something not even being discussed today such as a way for the HTML5
<video> tag to support WebSocket URLs, with a way to transport video
over it (maybe RTP over WebSocket?).  That said, I have reservations
about using something built on top of TCP for streaming media, as you
have no way of skipping lost frames even if they are no longer useful
because their time has passed.

> This goes back to a statement you made regarding "real-world" applications
> for websockets.
>

At the time, the only two I knew of were Google Wave (hacked up to
operate over WebSockets) and GWT Quake, so that is what I measured.
There probably are others now.

> For example, interactive I/O notifications is an immediate benefit, thats
> pretty much a given everyone can see.
>
> But beyond that, it will be server-driven.  Are these extensions JS code,
> browser plug-ins?

Obviously, we only have ideas of extensions that might be implemented
at this point.  Some obvious ones I feel confident will be implemented
are some form of multiplexing (the scalability problems are
potentially severe without it) and some form of compression.  Neither
of these would likely be implemented with metadata  as it has been
discussed in my most recent proposal (though Greg would disagree on
multiplexing), since they alter the interpretation of the payload.
Those would all likely be implemented beneath any APIs on either the
server or the client (though for compression it might be useful to
have an API saying whether you should bother trying to compress a
message) -- the browser would just negotiate it with the next endpoint
and then transparently take advantage of it without any input from the
JS code, likewise on the server.

If a MIME-type extension were implemented, then that is something that
likely would require input via the API.

---

From: Pieter Hintjens <[email-masked]>
Date: Tue, 31 Aug 2010 19:19:19 +0200

On Tue, Aug 31, 2010 at 3:07 AM, John Tamplin <[email-masked]> wrote:

>...  It turns out there is one gotcha I ran into
> arbitrarily long

If the use case for fragmentation is streaming of arbitrarily long
messages whose size is unknown upfront (which is the only real use
case that's been cited afair, with reference to HTTP chunking), does
that also apply to the extension data?  If not, then the sender will
simply place the extension data, no matter how large, into a frame of
sufficient size, and we can mandate that extension data is never
fragmented.

-
Pieter Hintjens
iMatix - www.imatix.com

---

From: John Tamplin <[email-masked]>
Date: Tue, 31 Aug 2010 13:45:35 -0400

On Tue, Aug 31, 2010 at 1:19 PM, Pieter Hintjens <[email-masked]> wrote:
> case that's been cited afair, with reference to HTTP chunking)

The other main use case is for multiplexing, where you don't want
other logical channels blocked behind one sending a very large frame,
so you need to be able to fragment that frame.  Certainly, you could
define fragmentation within the mux payload, but it seems cleaner if
it can just reuse the fragmentation support defined in the base
protocol.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 31 Aug 2010 20:15:36 +0200

> it can just reuse the fragmentation support defined in the base

That's one point where I agree with what was said by Shelby, we should
not confuse fragmentation of the connection stream caused by multiplexed
data streams and fragmentation of messages caused by unknown (or too
long) message lengths.

I propose that we use the word "fragmentation" when we're talking about
mixed streams and "chunking" when we're talking about a known-sized chunk
of a possibly unknown-sized message (as we do in HTTP).

Thus, a "fragment" is the smallest part of a connection stream, and a
"chunk" is the smallest part of a message. As long as we don't support
multiplexing, both are probably identical on the wire, but I suspect
this can change with multiplexing (fragments then being able to transport
parts of chunks).

To ease understanding, one might want to think about what HTTP chunks
look like at the IP level. You'll see interlaced TCP segments related
to various streams, carrying portions of message chunks. BTW, maybe the
word "segment" should be used instead of "fragment" ?

We should also be careful not to reproduce the issues of IP vs
fragmentation, where it is easy to make the receiver reserve large
amounts of memory while waiting for a fragment that never comes. This
becomes especially important with multiplexing, because I suspect that
receivers will refresh their timeouts as long as at least one stream
talks on top of a connection.

Regards,
Willy

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 1 Sep 2010 08:24:39 +1000

> data streams and fragmentation of messages caused by unknown (or too

The extension mechanism we need in the framing layer should be for
extensions that cannot be done in the data layer, such as:
  + tagging frames with channel ID's for multiplexing
  + telling the framing layer hints like total message size for more
efficient buffering.

If there is a use-case for arbitrary long meta-data associated with a
message, then I think that should be sent as part of the message body
(eg as a mime message), so that can be fragmented the normal way.

So perhaps we should define another op-code for a mime message that
has headers (hopefully length rather than CRLF encoded) and data, and
can be fragmented normally.   Having this defined will help stop
misuse of the frame extension mechanism.

cheers

---

From: John Tamplin <[email-masked]>
Date: Tue, 31 Aug 2010 18:32:25 -0400

> this can change with multiplexing (fragments then being able to transport

I agree in principle, though there is a cost -- if we have chunking
for messages and then a separate fragmentation for multiplexing, we
will wind up having two lengths to define multiplexed frames (the
length of the chunk and the length of the fragment), wasting space.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Sep 2010 07:38:47 +0200

> length of the chunk and the length of the fragment), wasting space.

yes but not necessarily on every frame. The length of the chunk can
prefix the chunk, and for large enough chunks the overhead is very
low. And for small chunks (eg: typed text or SMS), it's probably
enough to have a "dont fragment" bit indicating that the length of
the chunk is the length of the fragment, which will most always be
the case anyway.

Willy