Subject: [hybi] Is there a traffic jam?

From: Mark Lentczner <[email-masked]>
Date: Mon, 13 Apr 2009 11:13:24 -0700

On Apr 11, 2009, at 7:27 PM, Greg Wilkins wrote:
> BEEP!
> ...
> BEEP!
> ...
> BEEP!
> ...
> BEEP!

As pointed out, BEEP has many attributes that make is seem a likely  
candidate for this space.

But, to summarize (and add to) the points against it:

Seems that each request/response would need its own BEEP channel. This  
is because of the synchronous nature of BEEP channels(*). Channel  
creation is mid-weight, but at least requires a round-trip before the  
actual request could even begin. It might be possible to encode the  
request within the channel creation request, but there is a 4k payload  
limit for such messages.

BEEP requires both XML and MIME parsers. Note that BEEP messages are  
not equivalent to HTTP messages.  BEEP has no address (URL) or method  
for the messages, and the headers of BEEP are MIME, whereas the  
headers of HTTP are not. One could imagine using the message/http MIME  
type to an HTTP message as the payload within a BEEP message. But then  
you'd need XML, MIME and HTTP parsers... This personally doesn't  
bother me, but it is getting rather heavyweight for something small.

There is no addressability in BEEP for channels or messages. I see two  
ways two add one to a profile: 1) Add the address (and perhaps method)  
as fields in the initialization message on channel create. This would  
require a new channel for every request. 2) Encode the address in each  
message (see above for using message/http)

Some unclear aspects:

The overhead of BEEP seems like it would greater, though I admit I  
haven't calculated it. I doubt it would be outrageous.

I don't know enough to know if flow control internally would be  
needed. If so, BEEP has it.  If not, it is a little scary to implement!

I think one could shoe-horn into BEEP via Upgrade with a little  
careful draftsmanship. Defining a fall-back mechanism might be  
considerably more difficult, as BEEP is considerably more general.

Lastly, we did consider BEEP about a year ago. The biggest thing  
against it was that libraries didn't seem widely available. I realize  
there is a chicken and egg thing here, but since BEEP didn't appear to  
really hit our use case dead on, we didn't feel like we'd be the best  
candidates to encourage its library development.

	- Mark

(*) There is a current draft addressing this: http://tools.ietf.org/html/draft-thomson-beep-async-02

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden
[email-masked]

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 13 Apr 2009 18:48:50 -0500

Hi Mark,

I don't have any opinion either way on the suitability of BEEP, other than to remark that it seems wasteful to retread old ground.  The conclusion might be subtly different; it might look like web-sockets, or it might be entirely different.

That's by-the-by.  As others have stated, more benefit might be gained by clearing the way for people who might like to use their own protocol.  Then they can make their own trade-offs.

> request within the channel creation request, but there is a 4k payload

[[MT]] BEEP does pipelining, just like HTTP.  Of course, the synchronous restriction is artificial, and there are use cases that demand a greater degree of asynchrony.  Hence, the draft you refer to.

> bother me, but it is getting rather heavyweight for something small.

[[MT]] The "XML" parsers I've seen in implementations of BEEP are rarely as complex as you make out.  The control channel doesn't demand much complexity of a parser.  Now you can take that as an indication of the maturity of BEEP implementation if you like, I can't disagree about _that_ point...

> message (see above for using message/http)

[[MT]] If you are looking to interact with the same resource, identifying the resource at channel creation time might make sense.  Alternatively, the MIME headers can be used to identify a resource for each request.

However, this as a problem for a certain set of assumptions.  This set of assumptions might vary greatly depending on your application.
 
> haven't calculated it. I doubt it would be outrageous.

[[MT]] Greater than websockets?  That seems quite likely.  Depends on how much you are using from of what BEEP offers.

> needed. If so, BEEP has it.  If not, it is a little scary to implement!

[[MT]] If you want to avoid implementation, it's not actually that hard to send an occasional SEQ frame.  It's quite easy to avoid flow control being a problem.  However, I'll note that flow control in current implementations isn't like that - a small fixed window is common, which severely limits throughput.  Of course, that's a further sign of stack maturity more than anything else, there is nothing in the protocol preventing bandwidth-delay product estimation.  

--Martin

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Ian Hickson <[email-masked]>
Date: Mon, 13 Apr 2009 23:53:31 +0000 (UTC)

On Mon, 13 Apr 2009, Thomson, Martin wrote:
>
> The "XML" parsers I've seen in implementations of BEEP are rarely as 
> complex as you make out.

Does this mean BEEP implementations don't reuse actual XML parsers?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 13 Apr 2009 19:01:00 -0500

Some do the right thing.  Others do what you might fear.

> -----Original Message-----
> From: Ian Hickson [mailto:[email-masked]]
> Sent: Tuesday, 14 April 2009 9:54 AM
> To: Thomson, Martin
> Cc: [email-masked]
> Subject: Re: [hybi] Is there a traffic jam?
>

---

From: Ian Hickson <[email-masked]>
Date: Tue, 14 Apr 2009 00:04:18 +0000 (UTC)

> Some do the right thing.  Others do what you might fear.

This is roughly why I believe one of our requirements should be that 
implementations should be possible in few lines of code without the use of 
any libraries. Sure, HTTP libraries are a dime a dozen, and we can rely on 
XML parsers and so on, but in practice, some will do the right thing, and 
others won't.

I'd rather have a protocol that's so simple that nobody will feel the need 
to write their own HTTP parser, say.

---

From: Paul Prescod <[email-masked]>
Date: Mon, 13 Apr 2009 17:12:03 -0700

> to write their own HTTP parser, say.

Do you have any evidence that people write their own HTTP parsers when
they use other protocols that run on top of or extend HTTP? Atompub,
WebDAV, SOAP, XML-RPC?

Why would web sockets programmers be more likely to write their own
HTTP parsers than other programmers?

 Paul Prescod

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 14 Apr 2009 10:18:52 +1000

> to write their own HTTP parser, say.

Ian,

the problem with a really simple protocol is that encourages wheels to
be reinvented further up the stack.

Not supporting features in the base protocol does not
make these things not a problem - it just makes them somebody
else's problem.

eg just because the base transport does not support multi-channel
interleaved messages with flow control, does not mean that
such requirements are not needed.

If for example we picked Websocket as *THE* protocol and
all the firewalls and gateways were changed to support upgrade
to websocket - then I would still expect to see many different
protocols being tunnelled over websocket datagrams.

These may be application specific protocols based on UTF-8
datagrams or they may even be existing protocols such as BEEP
tunnelled over websocket binary datagrams.

There would still need to be conventions or standards so
that we could work out that the websocket datagram really
does contain the protocol we are expecting, and then that
protocol will need to be implemented with all it's parsers
and libraries.

The question is - is there a reasonable subset of features
that could be supported at the base protocol level that
would reduce the number of reinvented wheels.

I really liked Jamie Lokiers suggestion of a set of optional
extension to HTTP, so that minimal implementations need only
implement the features that they need.   Thus support of
multiplexed interleaved messages with flow control would
not be manditory, but also would not have to be reimplemented
by every stack that needed it.

cheers

---

From: Rob Sayre <[email-masked]>
Date: Mon, 13 Apr 2009 20:22:09 -0400

> be reinvented further up the stack.

"The good thing about reinventing the wheel is that you can get a round 
one."

  - Rob

---

From: Mario Balibrera <[email-masked]>
Date: Mon, 13 Apr 2009 17:27:15 -0700

Doesn't that sound like exactly what everyone wants? Then we could all
implement our protocols, and expect them to work properly through the
dreaded proxies, all with a total overhead of one 0 byte and one 255 byte
per frame.

Mario Balibrera

On Mon, Apr 13, 2009 at 5:22 PM, Rob Sayre <[email-masked]> wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Ian Hickson <[email-masked]>
Date: Tue, 14 Apr 2009 00:38:11 +0000 (UTC)

On Mon, 13 Apr 2009, Paul Prescod wrote:
> > I'd rather have a protocol that's so simple that nobody will feel the 
> > need to write their own HTTP parser, say.
> 

These are all either highly complex protocols, which generally means that 
the implementors are more likely to be experienced and competent 
programmers, or they run "on top" of HTTP in a way that makes it easier to 
just write CGI scripts rather than work at the socket layer, and thus 
there's no HTTP parsing to do.

Authors _do_ write their own handlers for the parts of HTTP that aren't 
handled by Apache, like parsing query parameters or multipart/form-data, 
despite libraries for those existing too.

> Why would web sockets programmers be more likely to write their own HTTP 
> parsers than other programmers?

Because such servers are more likely to be standalone and written by 
inexperienced programmers.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 14 Apr 2009 10:39:35 +1000

Mario Balibrera wrote:
> dreaded proxies, all with a total overhead of one 0 byte and one 255 
> byte per frame.

Mario,

it does come close (although I'd expect the binary datagram with
lengths to be used more than the 0/255 sentinels around UTF-8)

But websocket does lack support for meta data so that you can
know what protocols are being tunneled over it.

The URL of the connection can be used to indicate what protocol
is being used, but that limits us to 1 protocol per connection.

In the multi widget/frame/tab/window scenario, picking one
protocol to run over websocket could be difficult/impossible.
The result would more likely be a new connection for each protocol
and that could easily devolve into one connection per
widget/frame/tab/window.

If there was just a smidge of meta data available per
datagram - then the ability to share a single connection
would be hugely enhanced.

If upgrading the network infrastructure is a once a
decade exercise, then I really think we should consider
that a minimal solution with limited extensibility
might not be the best next step.

I'd much rather see recommendations that would allow
arbitrary protocols to be supported by upgrades to
HTTP connections.   These would support websocket, but
also allow other protocols to try out for the
one-protocol-to-carry-them-all job.

cheers

---

From: Paul Prescod <[email-masked]>
Date: Mon, 13 Apr 2009 17:52:33 -0700

> inexperienced programmers.

Programmers who are comfortable writing reasonably scalable TCP
servers for binary protocols are unlikely to be "inexperienced." I am
quite surprised that you think that inexperienced programmers would
want to  write a protocol handler for a binary connection-oriented
protocol. This is likely to require multi-threading in most languages.
I think it far more likely that they would expect such a thing to be
implemented by the Apache foundation or the Python core team or
Microsoft. If the HTTP protocol is hard for these implementers, wait
until they learn about multi-threading!

 Paul Prescod

---

From: Ian Hickson <[email-masked]>
Date: Tue, 14 Apr 2009 01:00:31 +0000 (UTC)

On Mon, 13 Apr 2009, Paul Prescod wrote:
> Programmers who are comfortable writing reasonably scalable TCP servers 
> for binary protocols are unlikely to be "inexperienced."

I agree. But who mentioned scalable TCP servers for binary protocols? I 
want to let people like my dad write little scripts that do insignificant 
little things, just like today people write CGI scripts for all kinds of 
stuff. I want to let 12 year olds write multiplayer games. I want to let 
someone who picked up HTML on Monday and CSS on Wednesday try their hand 
at WebSockets on Friday. I want to support the intern whose boss told him 
to put one of those interactive chat widgets on the intranet.

> This is likely to require multi-threading in most languages.

It's easy to write simple TCP servers using a select() loop without 
threads.

To reiterate: I have no objection to there being many protocols 
standardised here. But I do want to make sure that at least one of them 
enables an inexperienced programmer to bang out an interactive toy in a 
few days without having to use libraries, just like they can bang out a 
CGI script today and get interaction in forms. Currently, of the various 
proposals, only one of them comes even close to this, IMHO.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 14 Apr 2009 11:08:57 +1000

Ian,

I think there is a big difference between protocol and API.

I understand that Websocket has addressed both wire protocol
and API in the same effort - and that I think is because those
involved have correctly identified that both need to be improved
to fix the general problem.

Having a simple approachable API for use by 12 year olds and
70 years old is great!     But there is not need for that
simplicity to be reflected in the protocol, or for the
protocol to not support other more complex APIs (or indeed
multiplexing of many instances of the simple API).

cheers

---

From: Paul Prescod <[email-masked]>
Date: Mon, 13 Apr 2009 18:14:45 -0700

> proposals, only one of them comes even close to this, IMHO.

You are moving the goal posts in a very unfair way.

You use the example of CGI scripts. Do you know anyone who runs CGI
scripts without Apache in front? The very definition of CGI is that it
is a tool that allows a front-end to handle the protocol and have a
back end handle the logic. If CGI is your example of a successful
technology, then HTTP is by analogy a protocol that has the right
level of complexity/power for its task.

Yes, you want your dad to write "WebSocket" scripts. I want my 12 year
old neighbour to be able to as well. Please do not assume that we have
different goals. But people like my twelve year old neighbour know CGI
and PHP. They do not know how to parse binary data coming in from a
socket. The humane thing to do is to PROVIDE a CGI or PHP or Rails
interface to the protocol. In substantially less time than it will
take to standardize a protocol, we could make Apache modules to
implement it. Surely this is better than telling them: "here's a
binary protocol. Good luck with that!"

You're constructing a completely unrealistic scenario, like when a
reality show tells a bunch of chefs that "for today's contest you may
not use knives!" Why would we ignore 30 years of computer engineering
experience that tells us that people can and should cooperate rather
than develop everything from scratch themselves? Do you expect your
Dad to write his own UTF-8 parser?

> I want to let 12 year olds write multiplayer games.

Please be very specific about HOW a 12-year old who knows PHP would
write a multiplayer game using PHP and WebSockets. Given how easy you
say it is, code samples would be appropriate. Tic Tac toe in
PHP/WebSockets would be a very helpful demonstration of the technology
and proposed programming model.

 Paul Prescod

---

From: Ian Hickson <[email-masked]>
Date: Tue, 14 Apr 2009 01:17:44 +0000 (UTC)

On Tue, 14 Apr 2009, Greg Wilkins wrote:
>
> Having a simple approachable API for use by 12 year olds and 70 years 
> old is great!  But there is not need for that simplicity to be reflected 
> in the protocol, or for the protocol to not support other more complex 
> APIs (or indeed multiplexing of many instances of the simple API).

The 12 year olds and 70 year olds in the scenarios I described are the 
people who would be writing the server-side components also. So yes, there 
is a _critical_ need for the simplicitly to be reflected in the protocol.

A simple protocol doesn't preclude more complex APIs, or multiplexing. 

For example, instead of having frames like this:

 +-FRAME-------------+-DATA----------------+
 | +-----+---------+ | +-----------------+ |
 | | ... | Channel | | | Message         | |
 | +-----+---------+ | +-----------------+ |
 +-------------------+---------------------+

...where the Channel part of multiplexing is a core part of the protocol 
that _everyone_ has to deal with, we can just as easily have:

 +-FRAME---+-DATA--------------------------+
 | +-----+ | +---------+-----------------+ |
 | | ... | | | Channel | Message         | |
 | +-----+ | +---------+-----------------+ |
 +---------+-------------------------------+

...where the Channel part is part of the application-level protocol. 
Instead of putting multiplexing into the core API and wire protocol, 
people can implement it using custom APIs and custom formats over the 
basic wire protocol.

This is just like the way that TCP has no support for individual blocks 
over a connection -- it's a streaming protocol. But we can layer blocks on 
top of TCP. That's not a failing of TCP.

(In these diagrams the "..." bit represents whatever other per-frame 
metadata we might have; in WebSockets right now this is just a frame type 
byte and a length for binary frames.)

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 14 Apr 2009 12:16:56 +1000

Ian,

Of course arbitrarily complex protocols can be tunnelled over
websocket.

But we can already tunnel arbitrary protocols over HTTP, so if
the ability to transport arbitrary protocols is sufficient, then
we are already there and nothing new is needed.

The question is - can we do something better than tunnelling
over HTTP.

To be frank, I'd actually rather use HTTP has a basis
than websocket.    The websocket wire protocol appears to
have focused on byte squeezing at the expense of meta data
and extensibility.

Byte-squeezing is simply not a pain point that I'm
experiencing while deploying bidirection webapplications.
Even the latency benefits of websocket are more perceived
benefits than any measurable improvement in average latency.

The pain points I'm having deploying bidirectional webapplications
are mostly about sharing connections:

  1) How to stop a browser sharing a connection by queuing
     normal requests behind long polled requests.
  2) How to share limited connections between
     widgets/frames/tabs/windows.
  3) How to limit the growth of connections on the server.

Websocket potentially helps with #1, but only if upgraded connections
are excluded from connection accounting (obvious to do, but not
sure if that is specified anywhere?).

Websocket doesn't help with #2 and #3 at all.  In fact it probably
makes it worse.  While individual connections are bidirectional, each
widgets will be able to each initiate their own websocket connection to
their own backend handling.  So the end result is likely to be a lot
more unshared connection.

cheers

---

From: Ian Hickson <[email-masked]>
Date: Tue, 14 Apr 2009 02:55:25 +0000 (UTC)

On Tue, 14 Apr 2009, Greg Wilkins wrote:
> 
> But we can already tunnel arbitrary protocols over HTTP, so if the 
> ability to transport arbitrary protocols is sufficient, then we are 
> already there and nothing new is needed.

Personally I think that having a single underlying TCP connection and the 
ability to do this across domains are pretty important new aspects.

> To be frank, I'd actually rather use HTTP has a basis than websocket.

As I've said before, I have nothing against people using HTTP, either 
straight up as is done today, or in some other protocol like rHTTP.

> The pain points I'm having deploying bidirectional webapplications are 
> mostly about sharing connections:
> 

WebSocket addresses this by not sharing TCP connections with regular HTTP 
traffic.

>     widgets/frames/tabs/windows.

WebSocket and SharedWorkers can be used together to get the number of 
long-lived connections per origin (domain) down to one.

>  3) How to limit the growth of connections on the server.

I don't know how to reduce it to less than one TCP connection per origin 
per user. I'm certainly interested in proposals that achieve this without 
sacrificing the other requirements.

> are excluded from connection accounting (obvious to do, but not sure if 
> that is specified anywhere?).

Since WebSocket isn't HTTP, the HTTP limit doesn't apply, as far as I can 
tell. However, I'm happy to edit the spec to make this clearer, or to 
introduce a limit if one should be imposed.

> Websocket doesn't help with #2 and #3 at all.  In fact it probably makes 
> it worse.  While individual connections are bidirectional, each widgets 
> will be able to each initiate their own websocket connection to their 
> own backend handling.  So the end result is likely to be a lot more 
> unshared connection.

I don't see any reason why this should be the case. Why would it be 
possible to use one pair of connections with HTTP today, but not use a 
single WebSocket connection in the future? Especially considering new 
mechanisms like SharedWorker, which allow resources from one origin to be 
shared across multiple tabs in a browser.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 14 Apr 2009 14:13:47 +1000

Ian Hickson wrote:

> single WebSocket connection in the future? 

Of course it is possible to share websocket connections just as we
currently share HTTP connections.

But sharing HTTP connections is currently painful and difficult and
relies on a variety of javascript/dom hacks.   It also needs protocol
support on top of HTTP to support the multiplexing.

Websockets does not help with this.  It will still be painful to
share connections and protocols to multiplex will still need to
be written on top of it.   However, with the more approachable
API of websockets, it is likely that it will be used directly
by widget/application developers (and it is "sold" as such), so
the probability of sharing/multiplexing frameworks being
widely used is small.

 > Especially considering new

Perhaps SharedWorkers may indeed help with sharing a connection.
Indeed such new features are going to be needed in the
browser to solve this issue regardless of the protocol used and
would equally apply to HTTP.

Note also that if such features do better support sharing of connections,
then good support for multiplexing becomes even more important.

regards

---

From: Ian Hickson <[email-masked]>
Date: Tue, 14 Apr 2009 05:27:25 +0000 (UTC)

On Tue, 14 Apr 2009, Greg Wilkins wrote:
> Websockets does not help with this.  It will still be painful to share 
> connections and protocols to multiplex will still need to be written on 
> top of it.  However, with the more approachable API of websockets, it is 
> likely that it will be used directly by widget/application developers 
> (and it is "sold" as such), so the probability of sharing/multiplexing 
> frameworks being widely used is small.

Come now. All you have to do to share a connection on the client is have a 
single object that does all the sending and receiving, with a 
corresponding piece of code on the server, which simply does three things:

1. To create a new "subconnection", sends a message, say "NEW" followed by 
a unique number followed by whatever information is needed to set up the 
remote end (e.g. the kind of widget), then hands back to the API caller a 
handle that is assocaited with the new unique number.

    "NEW 1 calendar-widget user=[email-masked]"

2. When sending a message given one of these handles, sends the number 
followed by whatever the message is.

    "1 add-event,2009-01-01,Holiday"

3. When receiving a message, strips off the leading number, then hands the 
rest of the message to the corresponding listener.

Why would this be painful? You can do it in JavaScript in barely 20 lines 
of code:

  function MultiplexConnection(url) {
    this.socket = new WebSocket(url);
    this.connections = {};
    this.lastID = 0;
    this.newConnection = function(callback, s) {
      this.lastID = this.lastID + 1;
      this.connections[this.lastID] = callback;
      this.socket.postMessage('NEW ' + this.lastID + ' ' + s);
      return this.lastID;
    };
    this.postMessage = function (handle, s) {
      this.socket.postMessage(handle + ' ' + s);
    };
    this.socket.onmessage = function (e) {
      var handle = e.data.substr(0, e.data.indexOf(' '));
      this.connections[handle](e.data.substr(e.data.indexOf(' ')+1));
    };
  }

The server side is only midly more complicated because of having to handle 
the "NEW" connections.

If you want to use a multiplexing framework, then you can write one (and 
make it available to people, if you want others to use it too). Doing so 
on top of WebSockets is easy. Whether other people do it or not is neither 
your problem nor mine, as far as I can tell.

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Tue, 14 Apr 2009 08:10:37 +0200

> one-protocol-to-carry-them-all job.

Indeed. I actually wonder in fact if the problem hasn't been addressed 
the wrong way around. It seems to me that we've had to discuss so far of 
a protocol that could basically work out for everything. But could it? I 
guess most people here have at some point implemented various protocols 
and feel like WS will not be good at supporting any of them without 
major headaches and hacks.

The question I have now is, what does precisely stop browsers from 
offering a raw TCP socket API at the Javascript level?

I assume there are two main reasons:

* security risks
* problems to go through firewalls, proxies, etc.

The answer to those so far has been WebSocket but is it the right way? 
The endless nitpicking of this list should probably be warning enough in 
my opinion that it might be the wrong path.

Personally I'd rather have a direct TCP socket access from the browser 
and let organisations decide if they should allow specific ports to be 
opened. Afterall, tunelling through HTTP might end up with those 
organisation sniffing traffic and deny HTTP Upgrade anyway.

- Sylvain
http://www.defuze.org

---

From: "S. Mike Dierken" <[email-masked]>
Date: Mon, 13 Apr 2009 23:17:57 -0700

> The question I have now is, what does precisely stop browsers 
> from offering a raw TCP socket API at the Javascript level?
> 
I thought that was available, via object/applet style plug-ins.

---

From: "S. Mike Dierken" <[email-masked]>
Date: Mon, 13 Apr 2009 23:17:57 -0700

I have the same wish - let most anybody write cool little event driven apps
in browsers and other web-enabled apps and devices.

However I do think that some of the heavy lifting and 'best practices'
should be done by the user-agents. I don't see that the raw low level byte
stream has to be presented to the casual programmer. But I also think the
low level stream can be simple enough for most slightly-more-than-casual
programmers to handle.

I don't understand what all the difficulty is around this discussion - the
rHTTP draft looks great & is pretty much was I was suggesting three years
ago. Let's put rHTTP into a browser and see what happens!

> I want to let people like my dad write little 
> scripts that do insignificant little things, just like today 
> people write CGI scripts for all kinds of stuff. I want to 
> let 12 year olds write multiplayer games. I want to let 
> someone who picked up HTML on Monday and CSS on Wednesday try 
> their hand at WebSockets on Friday. I want to support the 
> intern whose boss told him to put one of those interactive 
> chat widgets on the intranet.

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Tue, 14 Apr 2009 09:06:43 +0200 (CEST)

> I thought that was available, via object/applet style plug-ins.

But if that was the solution we wouldn't have this discussion. It's
because people want to/have to write their application in javascript that
there is a need for a better solution than what exists now.

Perhaps the reason BEEP has never taken off is because it's so versatile
that it ultimately creates a bigger mismatch. I'm afraid WS might follow
the same trend.

- Sylvain
-- 
Sylvain Hellegouarch
http://www.defuze.org

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 14 Apr 2009 17:10:54 +1000

Ian,

implementing multiplexing is not the pain point as there are a million
ways to do it, ranging from trivial to amazingly complex.   We
can multi-plex over HTTP, yet it is still a paint point.

The problem is getting everybody to agree to share and use
the same multiplexing.

Websocket presents a nice simple interface that is easy for web developers
to use directly.  So they will use it directly!    As well as that, there
will be dojo/jquery/prototype/mootools/yahoo/ext/etc wrappers.   The
situation on the server side is even more diverse with regards to servers
and frameworks.

There is ZERO chance that all these diverse communities will come together
and decide on how to share and multiplex connections.   Websockets will
simply encourage direct consumption of connections.  If you are really
lucky, some frameworks might do their own multiplexing between their
own widgets and frames.    But with websocket, it simply will not
happen that a common standard will easily/quickly emerge for sharing and
multiplexing.

regards

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 14 Apr 2009 17:36:51 +1000

> my opinion that it might be the wrong path.

Well as one of the prime nitpickers.... I don't actually think it is
endless.

So sorry if it seams that I'm endlessly picking on websocket.
Not my intention - but it has been a convenient straw man to
illustrate that a simple protocol is not going to resolve some
outstanding issues, as BEEP has been a straw man to show that
a more complex protocol is going to have overheads that some
find unacceptable.

The conversation has been worthwhile (at least for me).  I'm
moving away from my "let's not pick winners" advocacy towards
a base protocol that does support sharing and multiplexing.
The HTTP extensions that Jamie described sound very interesting!

cheers

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Tue, 14 Apr 2009 09:42:37 +0200 (CEST)

> Well as one of the prime nitpickers.... I don't actually think it is

I apologise if you felt I was targetting you. It wasn't my intention at all.

> a more complex protocol is going to have overheads that some

Much agreed.

> a base protocol that does support sharing and multiplexing.

I'm still not convinced about the idea of a base protocol myself.

- Sylvain
-- 
Sylvain Hellegouarch
http://www.defuze.org

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 14 Apr 2009 10:03:31 +0200

> major headaches and hacks.

This hasn't really been demonstrated. Some people feel that what goes over  
the wire should be identifiable as an intrinsic part of the protocol, but  
I'm still out as to why this is important. (I.e. something more than just  
"string" vs "bytes" vs "...".)

One concern that was raised is that library authors might not work  
together to do things in common. However, library authors already work  
together on common things, such as supporting the same query language,  
ways of allowing multiple libraries to be used by a single page, et  
cetera. There's a whole "alliance" based around this.

> offering a raw TCP socket API at the Javascript level?

The same-origin security policy.

> my opinion that it might be the wrong path.

It seems to me that the metadata point is endlessly repeated. I'm not sure  
if that should be an indication of "wrong path" or "clearly entrenched".

> organisation sniffing traffic and deny HTTP Upgrade anyway.

The closest to raw TCP socket access we can offer is something that looks  
like Web Sockets.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 14 Apr 2009 01:28:31 -0700

On Apr 14, 2009, at 1:03 AM, Anne van Kesteren wrote:

>
>
>> Personally I'd rather have a direct TCP socket access from the  
>> browser and let organisations decide if they should allow specific  
>> ports to be opened. Afterall, tunelling through HTTP might end up  
>> with those organisation sniffing traffic and deny HTTP Upgrade  
>> anyway.
>
> The closest to raw TCP socket access we can offer is something that  
> looks like Web Sockets.

Actually, we could offer closer to raw TCP socket access by providing  
a raw undelimited octet stream without message boundaries or text  
encoding, after the initial HTTP-upgrade handshake.  I do not think  
that this would actually be more useful however. I am sympathetic to  
imposing the minimal structure needed to act as a good transport, both  
for trivial direct use and for layering more structured protocols on  
top. But I do think that minimal amount of structure is greater than  
0. Partitioning message boundaries and offering direct support for  
sending and receiving text and not just bytes are among the useful  
minimal structure to provide. In my opinion, optional but well-defined  
subprotocol identification is another way, since it enabled building  
more structured protocols on top in a clear way.

Here's one way to think about it: a protocol with too much structure  
can make it hard to build other structured protocols on top. It is too  
opinionated, and it becomes hard to go against the grain. But a  
protocol with 0 structure also makes things difficult, because then  
it's hard to coordinate between independently controlled endpoints.

I think multiplexing multiple message streams, though it may seem  
useful at the protocol level, is not a critical building block. First,  
if WebSocket allows for reasonable protocol negotiation, one can  
easily build a multi-WebSocket-over-WebSocket protocol with little  
additional overhead. Second, opening multiple WebSockets to the same  
server is not necessarily a disaster. Third, for the "many widgets in  
one page" scenario, it's likely the widgets will actually want to talk  
to different servers. And finally, for a fully custom protocol,  
multiplexing can be implemented at the client/library level for  
application-specific needs. And I think supporting multiplexing  
directly in the base protocol may actually make life harder for cases  
like Atom-over-WebSocket, CalDAV-over-WebSocket, Jabber-over-WebSocket  
and other such purpose-specific but widely applicable protocols that  
we may see invented. Such protocols would have to work around the  
extra complexity imposed by the protocol-level multiplexing.

Regards,
Maciej

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 14 Apr 2009 11:53:55 +0200

On Tue, 14 Apr 2009 10:28:31 +0200, Maciej Stachowiak <[email-masked]>  
wrote:
> In my opinion, optional but well-defined subprotocol identification is  
> another way, since it enabled building more structured protocols on top  
> in a clear way.

It seems to me that the path can be used for that, but that is not formal  
enough for your taste currently as I understand it (it's not  
well-defined). Any ideas as to what would work better? Or maybe as to how  
to make the path fit the criteria?

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Tue, 14 Apr 2009 12:04:56 +0200 (CEST)

> "string" vs "bytes" vs "...".)

I would assume for multiplexing over one single WS connection. Mind you
the protocol could also impose connections can't be shared.

> The same-origin security policy.

I can appreciate this being a serious issue but somehow I'm fuzzy as to
why the response to that is a new base protocol other protocols should
interface with. From the browser's perspective, I can see why this is so
simple when I go through the WS specification but from a server's
perspective this means adding another layer which means:

* Having to understand for each protocol (XMPP, IMAP, etc.) the best way
to channel said protocols into the WS constraints.
* Having to gauge how to scale such infrastructure.

I find it odd to throw years of experience from the server side to fix one
security issue (even such a serious one).

> The closest to raw TCP socket access we can offer is something that looks

I find that seriously limitating.

- Sylvain
-- 
Sylvain Hellegouarch
http://www.defuze.org

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 14 Apr 2009 12:19:25 +0200

On Tue, 14 Apr 2009 12:04:56 +0200, Sylvain Hellegouarch <[email-masked]>  
wrote:
> interface with.

I'm not necessarily opposed to supporting other protocols natively in the  
browser.

> From the browser's perspective, I can see why this is so

They would need to fit similar constraints at least if they were to be  
exposed to JavaScript.

> I find it odd to throw years of experience from the server side to fix  
> one security issue (even such a serious one).

Odd or not, it remains a design constraint.

> I find that seriously limitating.

It is, but there does not seem to be a better way either.

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Tue, 14 Apr 2009 12:39:18 +0200

> They would need to fit similar constraints at least if they were to be 

Would it? If there was direct access to raw TCP sockets there would be 
no requirements for a change in infrastructure, it would only mean 
client libs have to be written for each supported protocol, like in any 
other language.

> It is, but there does not seem to be a better way either.

Since I have no real knowledge of the browsers' design constraints, I 
can't really offer alternatives.

- Sylvain

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 14 Apr 2009 15:17:44 +0100

> I'm still not convinced about the idea of a base protocol myself.

WebSockets is a base protocol.

Are you advocating raw TCP?

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 14 Apr 2009 15:44:02 +0100

> It's easy to write simple TCP servers using a select() loop without 

It's easy to write a simple HTTP server using a select() loop too, if
you know unix, or Perl, or Python.  There are lots of bad ones around
to prove it.  It's even easier with fork().

But mostly people use big HTTP servers written by other people and hang
applications off the back now, using CGI/FastCGI/WSGI/mod_*/ etc.

I expect your dad / 12 year old / person who picks up HTML on Monday
will use Apache or similar with a CGI or similar backend to their
favoured programming language.

They probably don't care much about HTTP, just that it calls their
application when a page is requested.  And they probably don't know
anything about unix system calls.

So on Friday they'd rather use Apache with a "hybi-CGI" backend to
their favoured programming language, than write their own select() loop.

The important thing for that scenario is that "hybi-CGI" must be easy
to understand and use.  Whether that's because it's so trivial anyone
can write TCP/WebSockets in good programming languages, or because the
protocol fits into widely used CGI-like frameworks in a way people
understand.

Right now, AJAX is widely used, and polling-AJAX is widely used for
server-driven updates to web pages because people find it easy to
understand, and it's easy to use existing frameworks - just another
tiny web page (fragment) to serve.

Indeed a lot of people think polling-AJAX is the most efficient way to
keep bits of a web page updated.  From a CGI-writing point of view,
that's true.  (From my point of view it's obviously false.)

For those people (imho the majority), what's most important is that
their preferred CGI-like framework supports the new protocols and
doesn't change the way they program too much.

Of course we'd like to support people who are happy writing their own
low-level server implementations too, and work well in that case.

> proposals, only one of them comes even close to this, IMHO.

Which one?

(I've designed my flavour of asynchronous HTTP to fit banging out
extended-CGI/etc. services like a glove, while also addressing
TCP-style streaming/messaging services.  I think WebSockets (without
metadata) does not fit the CGI-style usage as well, but it's
interesting to see the perspectives and differing requirements being
expressed.)

-- Jamie

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Tue, 14 Apr 2009 18:47:37 +0200

> Are you advocating raw TCP?
I am yes.

- Sylvain

---

From: Mario Balibrera <[email-masked]>
Date: Tue, 14 Apr 2009 09:57:50 -0700

Lightweight WebSocket proxies exist (check out the dez project), and are
trivial to deploy.

The fact is, the people who want CGI-like interactions already have plenty
of tools that perfectly fit their use-case, and they don't need another one.
We're all here because the current toolset does not sufficiently address our
needs. We don't have to create something incompatible with existing
frameworks, but the very nature of CGI is in diametric opposition to the
concept of a streaming protocol. It's clear that people working in CGI-like
frameworks will _have_ to change the way they program, because they will be
writing applications that are fundamentally different.

Note that different != harder. Anyone in the world can write a CGI script
because anyone in the world can type "cgi script" into google and get a
thousand code snippets to paste in. Writing actual network applications is a
big secret only because no one's writing the tutorials. (We should start).

Mario Balibrera

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 14 Apr 2009 18:15:22 +0100

> [[MT]] BEEP does pipelining, just like HTTP.

Yes, that's why it sucks :-)

HTTP pipelining is a problem.  Have you noticed that no sane client
sends pipelined POSTs?  There's a reason.

Have you noticed that proxies do not aggregate multiple clients into
fewer connections to the same origin server?  Pipelining not being
asychronous is the main reason why they can't.

For widgets in a web page, the BEEP synchronous restriction forces
application workarounds for "large" messages - such as a large PNG (or
unwanted interference as soon as you mix widgets on a page) - and it
forces each application to have its own addressing layer _above_ the
base protocol if they have multiple widgets on a page all subscribing
for updates which can come in any order.

Basically it prevents lots of widgets from operating independently of
each other over the same channel.  Use separate channels (or server
connections) for a few widgets?  That doesn't scale to 100 or more
widgets per page, which is easy to reach with a bit of imagination.

> Of course, the synchronous restriction is artificial, and there are
> use cases that demand a greater degree of asynchrony.  Hence, the
> draft you refer to.

Unfortunately the asynchrony draft still has an artifical restriction
which makes it useless for independent requests.

> [[MT]] The "XML" parsers I've seen in implementations of BEEP are
> rarely as complex as you make out.  The control channel doesn't demand
> much complexity of a parser.  Now you can take that as an indication
> of the maturity of BEEP implementation if you like, I can't disagree
> about _that_ point...

To be a "correct" BEEP implementation, it needs to correctly parse
XML, including skipping a potential embedded DTD (whose lexical syntax
wasn't even precisely defined in the XML spec last time I looked),
accepting UTF-16 both endians, and things like that.

No problem if you have a good XML library handy, only if you don't.
(Still a bit heavy even if you do, compared with HTTP's headers.)

_Normal_ XML is easy to parse in any language, the problem is a
protocol implementation is allowed to send unusual XML, and a protocol
parser which doesn't handle that is non-compliant.

Is there a new BEEP planning to come out which specifies that the
irrelevant parts of XML will not appear on the wire?  That would be
helpful.  I'm sure I've seen that done in some other IETF documents.

> [[MT]] If you are looking to interact with the same resource,
> identifying the resource at channel creation time might make sense.
> Alternatively, the MIME headers can be used to identify a resource for
> each request.

I agree with both of those; they make sense to me.

My only objection is that BEEP channel creation needs a round trip -
you can't create them at the request side as needed.

> [[MT]] Greater than websockets?  That seems quite likely.  Depends
> on how much you are using from of what BEEP offers.

Overhead: the initial setup looks similar for each.  After that, BEEP
uses more bytes, but about the same number of network packets.

> [[MT]] If you want to avoid implementation, it's not actually that
> hard to send an occasional SEQ frame.  It's quite easy to avoid flow
> control being a problem.

Indeed.  Per channel flow control is important - if you have multiple
independent channels, otherwise problems you don't want to care about
bite some applications.

> However, I'll note that flow control in current implementations
> isn't like that - a small fixed window is common, which severely
> limits throughput.  Of course, that's a further sign of stack maturity
> more than anything else, there is nothing in the protocol preventing
> bandwidth-delay product estimation.

Agreed.  Also SCTP instead of TCP is promising - let the operating
system do the estimation for you better.  (There's some discussion of
HTTP over SCTP around, but nothing concrete yet that I know of.)

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 14 Apr 2009 18:45:09 +0100

Mario Balibrera wrote:
> We don't have to create something incompatible with existing
> frameworks, but the very nature of CGI is in diametric opposition to
> the concept of a streaming protocol.

No.  It's different, but there are ways to bring them quite close
together for a lot of practical applications.  It's far from
diametrically opposed, you just need good glue in the middle to hide
the protocol differences.

> It's clear that people working in CGI-like frameworks will _have_ to
> change the way they program, because they will be writing
> applications that are fundamentally different.

I disagree.  Some applications must be structured differently to work
well.  But many don't need radical changes, especially when efficiency
at the server is not a great concern.

For example, an application with:

    - Data stored in a database and/or files.
    - A HTML templating system.
    - A template containing HTML, references to other templates,
      and snippets of code generating some HTML based on the stored data.
    - The output must appear as either a whole web page, or embedded
      in part of a larger one.

That comprises probably 99%+ of dynamically generated web pages at the
moment (which don't update themselves).  Nearly everything which isn't
an interactive form fits that pattern.

Now you, the (CGI-level :-) programmer, are asked to do the same, but
it must update changed parts of the page in the browser, immediately
when the stored data updates.  (I'd say a lot of collaborative
editing, chatting and data presentation falls into that category.
Many widgets could do.  Are we still at 99%?)

Despite the use of asynchronous server events on the wire, it's
possible to implement that in CGI with the right glue.

In fact it's possible in some cases without changing the CGI script.

I'm told Microsoft already has a version of ASP.NET which does it by
regenerating whole pages on the server side and comparing with
previous output to decide when to send an update, and what to send.  I
don't know if it's smart enough to figure out _when_ to recalculate
those pages.

There are cleverer ways to do it with less calculation and only when
the requisite data changes, while still structuring the code as if
it's classic CGI and templating + database/file queries.

I'm not saying all applications should be written that way, but when
it works and especially when it works efficiently - why not?  It's a
good way to write applications when it works.

> big secret only because no one's writing the tutorials. (We should start).

I expect the same snippets as soon as we have CGI scripts (+ Python,
Java frameworks etc.) which do clever two-way interactive things with
widgets.

The only difference will be "this script requires hybi-CGI support in
the web server for the dynamic parts to work" or whatever the
framework is called.

If people would like more discussion on techniques for client update
which don't require long-running server-side applications at the CGI
level (only the web server itself must manage those connections on
behalf of the application), I could expand on it but I expect there's
plenty of people here who have implemented that sort of thing already,
and the web isn't short of comet tutorials.

-- Jamie

---

From: Mike Dierken <[email-masked]>
Date: Tue, 14 Apr 2009 11:36:44 -0700

I was thinking the applet would expose the 'web socket' API (or
equivalent) and the app would be built with JavaScript. This would be
a way to prototype an approach that created a sibling of
XMLHttpRequest, but meant for receiving unsolicited requests in a page
- something like XMLHttpServer (but without the XML part).

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 14 Apr 2009 20:30:50 +0100

> that it ultimately creates a bigger mismatch. I'm afraid WS might follow

The BEEP web page suggests it's used more than you think.

I suspect not so much versatility (HTTP is versatile), as it's too
basic for a lot of applications.  You have to write your own stuff on
top of it, so you might as well go all the way and use TCP or SSL,
which isn't much harder and doesn't require you to learn another library.

Or at the other end of the scale, useing HTTP or something ugly like
SOAP containing a short string wrapped in 1k of pointlessness, because
that's provided by well known libraries and the handy
metadata/extensibility means you don't have to design your own way to
add those things ad hoc.

-- Jamie

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 14 Apr 2009 13:04:39 -0700

On Apr 14, 2009, at 2:53 AM, Anne van Kesteren wrote:

> On Tue, 14 Apr 2009 10:28:31 +0200, Maciej Stachowiak  
> <[email-masked]> wrote:
>> In my opinion, optional but well-defined subprotocol identification  
>> is another way, since it enabled building more structured protocols  
>> on top in a clear way.
>
> It seems to me that the path can be used for that, but that is not  
> formal enough for your taste currently as I understand it (it's not  
> well-defined). Any ideas as to what would work better? Or maybe as  
> to how to make the path fit the criteria?

Here's some possibilities that I think are better than leaving it  
completely undefined.

1) Optional HTTP response header for protocol type in the server  
handshake response.

2) Define that part of the path defines the type - this could be (a)  
the first path segment, (b) everything after the last dot (the  
"extension", though that is weird to use for protocol type since for  
server side scripts the extension often just reflects the  
implementation technology) or (c) a semicolon-delimited "parameter"  
which is otherwise not much used in the URI syntax.

3) A dedicated initial pair of messages over the channel with a  
specific format.

I think of these solutions, (1) is the cleanest. There's probably  
other possibilities I didn't think of.

Regards,
Maciej

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 15 Apr 2009 08:49:06 +1000

> - something like XMLHttpServer (but without the XML part).

Having access to TCP does not really help much.

You still will not be able to tunnel through many firewalls
and proxies without pretending to be HTTP.

Also as a client/application API, raw TCP is pretty
difficult to code against.   What does an application do
with 2 bytes of a 6-byte UTF-8 character.

I very much like websockets abstraction of utf-8 datagrams
in the js/dom API.   This is very usable by applications
and/or frameworks (I just don't think the transport should
be skewed to support uncompressed UTF-8 datagrams without meta
data.)

cheers

---

From: Mike Dierken <[email-masked]>
Date: Tue, 14 Apr 2009 17:04:19 -0700

I was just pointing out that if someone wanted TCP access, they could
do that easily with an very small applet.

I personally wouldn't want just TCP access - I would prefer that the
browser make it easy for a web app author to connect to a 'helper'
service (due to firewalls not allowing inbound connections), register
that the web app hooks into a particular URI namespace (so other
participants in the application have a URI to send messages to), and
for the browser to deliver "Request" objects (and maybe a Response
object as well) to a registered handler function implemented in
JavaScript. The per-app or per-URI dispatching to multiple handlers is
simple enough that this wouldn't need to be standardized up front and
the app developer could do it however they want - as long as the
Request object has the key elements of URI, method, headers and
content.

Is that too much to ask for? ;)

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Wed, 15 Apr 2009 09:17:07 +0200 (CEST)

> The BEEP web page suggests it's used more than you think.

Well to be fair, those applications don't look so much as being used on
the web itself but rather internally. It's quite easy to adapt to a
protocol when you don't have the constraints of a global network you don't
control.

> which isn't much harder and doesn't require you to learn another library.

Much agreed and that's the point I was tyring to make :)

> metadata/extensibility means you don't have to design your own way to

You don't say :)

- Sylvain
-- 
Sylvain Hellegouarch
http://www.defuze.org

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Wed, 15 Apr 2009 09:35:02 +0200 (CEST)

> and proxies without pretending to be HTTP.

But that's exactly the point, isn't it? Instead of reinventing the wheel
to go through firewalls and proxies, you reuse what's been defined,
refined and tested over decades of networking.

Corporations will always want at some point to control their traffic, they
have already administrators that know how to handle the basic TCP routing.
Here we are trying to defeat that but ultimately software will be upgraded
to filter WS anyway if required. You just add a layer of complexity to the
game. I fail to understand the value in that. Why not educating players in
the game to play fair? Port 80 is spoiled more and more and that means
it's more and more complex to perform proper security without basically
shutting down almost anything going through.

> with 2 bytes of a 6-byte UTF-8 character.

It doesn't seem to have blocked the software industry so far. Libraries
handle those issues and offer higher level of abstraction for any given
protocol. JavaScript is short in those so far precisely due to the
constraints of not having access to raw TCP sockets I believe.

Why is the browser so different from anything else?

>From my perspective it's just one more layer of complexity.

- Sylvain
-- 
Sylvain Hellegouarch
http://www.defuze.org

---

From: Mark Lentczner <[email-masked]>
Date: Wed, 15 Apr 2009 18:35:10 -0700

Wow - the only traffic jam seems to be in my in-box! My this mailing  
list has gotten popular!

I tend to agree with the arguments against a minimal protocol such as  
WebSockets:
+1: there's nothing wrong using existing libraries for things like  
HTTP, XML, UTF-8, etc...
+1: inexperienced programmers are going to code to an API like CGI,  
not write the whole server
+1: you can make a good, easy to use API even for a rich protocol: to  
wit: CGI
+1: if the protocol is too minimal, the commonly used stuff will be  
implemented up the stack, which means:
	a) it will be non-interoperable
and	b)the infrastructure will not be able to interact with it

Other things I noticed:
- HTTP over SCTP *does* seem interesting. It might be nice to separate  
out the channeling and asynchrony from the bi-directionality. Now if  
we could do that, and have a fall back for today (not much SCTP in  
stock OSes...)... that is an interesting direction...
- Tunneling through existing firewall and proxy constraints seems to  
keep rearing its head. This feels to me like a separate concern: We  
should design what we think is useful, expect that in a few years  
firewalls and proxies will adapt, *and* design a pure HTTP fallback  
that will allow us to "get on with it" today.

	- Mark

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden

---

From: Paul Prescod <[email-masked]>
Date: Thu, 16 Apr 2009 11:26:21 -0700

It is obvious that the websockets design is heavily influenced by the
use case of a relatively inexperienced web programmer programming
directly against the API. Therefore, I would greatly appreciate an
answer to the question of how *precisely* that would work. If the
requirement to be directly implementable by inexperienced programmers
is key to the design, then please describe how this happens in your
proposed design?

Code or pseudocode or narrative are all fine. I'd just like to know
how you go about writing a WebSockets server in PHP. Roughly how many
lines of code is it, what libraries do you need to use, how do you
handle multiple overlapping incoming connections, and how do you
manage state?

On Mon, Apr 13, 2009 at 6:14 PM, Paul Prescod <[email-masked]> wrote:
> write a multiplayer game using PHP and WebSockets.
>
>  Paul Prescod
>

---

From: Ian Hickson <[email-masked]>
Date: Thu, 16 Apr 2009 18:57:00 +0000 (UTC)

On Thu, 16 Apr 2009, Paul Prescod wrote:
> requirement to be directly implementable by inexperienced programmers is 
> key to the design, then please describe how this happens in your 
> proposed design?

I haven't ignored this e-mail, I just can't send out a reply to it in 
three minutes, and have a couple of tasks I need to get done ASAP. I 
intend to reply to this e-mail and a number of others later this week or 
early next week.

---

From: Paul Prescod <[email-masked]>
Date: Thu, 16 Apr 2009 12:01:25 -0700

Thank you.  I only brought it up again because the pace of email is so
high that posts from a few days ago seem "buried" and lost.  I
understand that one cannot do everything at once.

 Paul Prescod

---

From: Ian Hickson <[email-masked]>
Date: Fri, 24 Apr 2009 06:11:25 +0000 (UTC)

> write a multiplayer game using PHP and WebSockets.

I don't know about a 12-year old who knows PHP, but a 12-year old who 
knows, say, Perl, could do it something like this for the server side:

   http://www.damowmow.com/playground/demos/websocket/tic-tac-toe.pl

...and something like this for the client side:

   http://www.damowmow.com/playground/demos/websocket/tic-tac-toe.html

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 24 Apr 2009 01:38:07 -0500

Because all 12 year olds use strict and -T.

I must admit that my perl is getting a wee bit rusty, but that's a non-trivial piece of code.  

I hope that you are about to argue that most of that code is going to be provided by Net:WebSocket or something similar.  Otherwise, there's more than enough rope left there to hang a number of software engineers that I know (admittedly, not the better ones).

--Martin

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ian Hickson
> Sent: Friday, 24 April 2009 4:11 PM
> To: Paul Prescod
> Cc: [email-masked]

---

From: Ian Hickson <[email-masked]>
Date: Fri, 24 Apr 2009 07:02:25 +0000 (UTC)

> Because all 12 year olds use strict and -T.

I was using their equivalents in the language(s) I used when I was 12. 
It's good hygiene. But it doesn't really matter either way for this code.

> non-trivial piece of code.

Come now. It's barely 100 lines of code, just doing basic network I/O. My 
friends and I were writing far more complex code at 12, and I'm hardly a 
good programmer. Most of the constructs are copied straight from online 
tutorials on Perl networking.

> I hope that you are about to argue that most of that code is going to be 
> provided by Net::WebSocket or something similar.

It seems reasonable for such a library to exist, but I don't think it is 
reasonable to expect that libraries will exist, no. That's the point. You 
don't need a library. It's no more than a couple of hours' worth of coding 
for a novice like me (I'm no professional programmer).

> Otherwise, there's more than enough rope left there to hang a number of 
> software engineers that I know (admittedly, not the better ones).

The same could be said of "Hello World" in most languages, especially 
Perl. Just think how much more complex this example would be if the 
protocol was more than just sentinel-delimited frames. :-)

---

From: Paul Prescod <[email-masked]>
Date: Fri, 24 Apr 2009 00:12:20 -0700

A few thoughts:

 1. It boggles my mind that you think that that is the kind of code that
"novices" will write. This is my main point. Everything that follows is of
lesser emphasis.

 2. I do not understand why you wish to inflict this kind of low-level Unix
hacking on novices. Even presuming that they can learn it from "WebSockets
for dummies", they will likely just skip the explanation and type it in as
cargo cult software.

 3. What happens when your tic-tac-toe server gets popular? Does this code
scale?

 4. Proper software engineering would suggest that you should split the
reusable bits from the application logic. Having done this, you will have a
"WebSockets library". At that point, you will never need to worry about 1
through 3 again, and neither will anyone else. But the problem is, once
you've done this, you've undone the very reason that you made the protocol
so simple-seeming in the first place. So you, Ian Hickson probably won't do
that. But someone will do it and no Perl programmer will ever care about the
details of how to parse WebSockets again. On the other hand, when they get
out their trusty TCPDUMP tool, they'll see this crud on the wire:

 0x48,0x54,0x54,0x50,0x2f,0x31,0x2e,0x31,
0x20,0x31,0x30,0x31,0x20,0x57,0x65,0x62,

0x20,0x53,0x6f,0x63,0x6b,0x65,0x74,0x20,
0x50,0x72,0x6f,0x74,0x6f,0x63,0x6f,0x6c,

0x20,0x48,0x61,0x6e,0x64,0x73,0x68,0x61,
0x6b,0x65,0x0d,0x0a,0x55,0x70,0x67,0x72,

0x61,0x64,0x65,0x3a,0x20,0x57,0x65,0x62,
0x53,0x6f,0x63,0x6b,0x65,0x74,0x0d,0x0a,

0x43,0x6f,0x6e,0x6e,0x65,0x63,0x74,0x69,
0x6f,0x6e,0x3a,0x20,0x55,0x70,0x67,0x72,
                                             0x61,0x64,0x65,0x0d,0x0a

In other words, I strongly believe that you are optimizing for the wrong
thing. Slightly easier parsing is not as important as readability of the
protocol, in my opinion. I cannot tell you how many times in a month I do
this:

# telnet localhost 11211
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
stats
STAT pid 2202
STAT uptime 7567475
...

(that's memcached -- but I've never written a memcached client)

# telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
GET / HTTP/1.1
Host: www.slate.com

# telnet localhost 22
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3

Protocol mismatch.
Connection closed by foreign host.

Even SSH at least gives me a readable introductory string to tell me what
protocol is running and that the server is alive and kicking.

---

From: Paul Prescod <[email-masked]>
Date: Fri, 24 Apr 2009 00:18:00 -0700

On Fri, Apr 24, 2009 at 12:02 AM, Ian Hickson <[email-masked]> wrote:

> reasonable to expect that libraries will exist, no.

WHY NOT????

Libraries for UTF-8 exist. Libraries for XML exist. Libraries for EDI exist.
Libraries for SGML exist. Libraries for TCP sockets exist. Libraries for
every important standard under the sun EXIST. Why will WebSockets be a
unique and special case?

Why wouldn't libraries for Net::WebSocket exist? What kind of bizarro
universe do you anticipate where people prefer to go hunt down bits of code
from tutorials AND like to read protocol specs AND like to implement them
*themselves*, rather than just install libraries from CPAN? Are these
novices masochists?

 Paul Prescod

---

From: Ian Hickson <[email-masked]>
Date: Fri, 24 Apr 2009 08:04:05 +0000 (UTC)

On Fri, 24 Apr 2009, Paul Prescod wrote:
> "novices" will write. This is my main point. Everything that follows is 
> of lesser emphasis.

I guess this is a matter of opinion. As I said in an earlier e-mail, most 
of the sample code was written by copying-and-pasting from tutorials.

> 2. I do not understand why you wish to inflict this kind of low-level 
> Unix hacking on novices. Even presuming that they can learn it from 
> "WebSockets for dummies", they will likely just skip the explanation and 
> type it in as cargo cult software.

Well, as you say, for people who want them, libraries will probably exist.

> 3. What happens when your tic-tac-toe server gets popular? Does this 
> code scale?

No, of course not. It's written in perl. Writing code for 10,000 QPS loads 
is a whole different ball game than writing a tic tac toe game for one's 
friends at school.

> reusable bits from the application logic. Having done this, you will 
> have a "WebSockets library". At that point, you will never need to worry 
> about 1 through 3 again, and neither will anyone else.

The same could be said for CGI, yet people still write their own CGI 
parsers. The same could be said for URLs, or XML, or JSON, or any number 
of other Web technologies, yet people write their own URL parsers, their 
own XML parsers (heaven forfend), their own JSON parsers, etc.

> Even SSH at least gives me a readable introductory string to tell me 
> what protocol is running and that the server is alive and kicking.

$ telnet damowmow.com 11111
Trying 208.113.210.27...   
Connected to damowmow.com.
Escape character is '^]'. 
HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: http://damowmow.com
WebSocket-Location: ws://damowmow.com:11111/tic-tac-toe

I don't really understand the problem.

---

From: Ian Hickson <[email-masked]>
Date: Fri, 24 Apr 2009 08:10:28 +0000 (UTC)

> every important standard under the sun EXIST. Why will WebSockets be a

It won't. It'll be just like XML, and SGML, and JSON, and URIs, and CGI, 
and HTML, and ...: despite the existence of high-quality libraries, people 
will write their own, and the more complex the language, the more of a 
mess it makes. As the poster child for this I present HTML, which 
hypothetically was an SGML application. SGML libraries, as you say, exist, 
so why did HTML processors not use them? HTML is so far removed from what 
SGML rules say it should be that even HTML4 basically admits that calling 
it SGML is a lie. Why is that, given that there are SGML libraries?

Why do some people implement their own hacky XML parsers when they 
implement BEEP, instead of reusing one of the many XML parser libraries?

Why does everyone under the sun reimplement their own URI parser, despite 
libraries existing and despite URI parsing actually being pretty 
complicated to get right?

> universe do you anticipate where people prefer to go hunt down bits of 
> code from tutorials AND like to read protocol specs AND like to 
> implement them *themselves*, rather than just install libraries from 
> CPAN? Are these novices masochists?

Why would people do it themselves for CGI, URIs, HTML, SGML, JSON, XML, 
etc, but _not_ WebSocket? Why would, as you say, WebSocket be a unique and 
special case?

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 26 Apr 2009 18:48:14 -0500

> complicated to get right?

I think that I can answer that - because the protocol _appears_ so simple, that folks think they can do better.  This might be pure ego, or it could be something as basic as the library API not meshing well with their application design.  By making the protocol simple, you've lowered the bar; by lowering the bar, you've made people write their own.

So why is that we heap derision on those who roll their own XML parser, then advocate the same behaviour for another protocol?  Is there some complexity line that is crossed where one is acceptable, but the other not?

--Martin

---

From: Ian Hickson <[email-masked]>
Date: Mon, 27 Apr 2009 01:01:44 +0000 (UTC)

On Sun, 26 Apr 2009, Thomson, Martin wrote:
> > 
> > Why does everyone under the sun reimplement their own URI parser, 
> > despite libraries existing and despite URI parsing actually being 
> > pretty complicated to get right?
> 
> I think that I can answer that - because the protocol _appears_ so 
> simple, that folks think they can do better.  This might be pure ego, or 
> it could be something as basic as the library API not meshing well with 
> their application design.  By making the protocol simple, you've lowered 
> the bar; by lowering the bar, you've made people write their own.

If the decision is between the following:

 - A complex-looking protocol that will be implemented a few times only

 - A simple-looking protocol that is actually rather complex that will be 
   implemented many times but often incorrectly

 - A simple-looking protocol that is actually simple that will be 
   implemented many times but mostly correctly

...then I guess I'll pick the third one. :-)

> So why is that we heap derision on those who roll their own XML parser, 
> then advocate the same behaviour for another protocol?

You can't write a fully-conforming XML parser in 100 lines of (normally- 
indented) Perl. It falls in the second category above (presumably; I 
would have thought it looked pretty damn complex personally, but I'm 
going with your theory here).

> Is there some complexity line that is crossed where one is acceptable, 
> but the other not?

I don't think it's a line, more of a continuum. IMHO reading a few bytes 
off the wire like in the WebSocket protocol is way easier than 
implementing a multi-state parser with the complexity of XML's.

But that's mostly academic -- according to your hypothesis, if the 
protocol looks simple, whether it is or not, people will implement it. 
Since making the protocol complex arbitrarily is bad language design, that 
just leaves us in the position of doing our best to make it as simple as 
we possibly can.

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 27 Apr 2009 16:04:29 +0100

>  - A complex-looking protocol that will be implemented a few times only

==> HTML

>    implemented many times but often incorrectly

==> HTTP

>    implemented many times but mostly correctly

==> :-)

> protocol looks simple, whether it is or not, people will implement it.

I think that's correct.

> just leaves us in the position of doing our best to make it as simple as 

I think WebSockets is in the unusual position that client browser
implementations won't be implemented often, but servers will be and so
will any Javascript layer that people need to put on top.

I guess that's why I push for more complexity in the client browser
implementation, in exchange for less complexity at the Javascript
level when you can't avoid putting it somewhere, for a broad class of
applications.

You can bet whatever people have to write in Javascript, will be
written many times over and badly.

-- Jamie

---

From: Ian Hickson <[email-masked]>
Date: Mon, 27 Apr 2009 18:17:26 +0000 (UTC)

On Mon, 27 Apr 2009, Jamie Lokier wrote:
> > 
> > Since making the protocol complex arbitrarily is bad language design, 
> > that just leaves us in the position of doing our best to make it as 
> > simple as we possibly can.
> 

Agreed.

> implementation, in exchange for less complexity at the Javascript level 
> when you can't avoid putting it somewhere, for a broad class of 
> applications.

I'm happy to add more complexity (so long as it is justified) to the 
client implementation, with the caveat that it must not also increase the 
complexity of the server-side implementations.

The client component has to deal with any server, including non-conforming 
servers sending back garbage, future servers that support an extended 
version of the protocol, etc. Server components only have to deal with the 
output possible from their own scripts driving a conforming implementation 
of the API. We can leverage that asymmetry.

This is why currently the spec for the client side defines the entire 
protocol (including binary frames which might be sent by servers in the 
future), but the spec for the server side only defines the rules required 
for handling content sent by the current client API.

---

From: Paul Prescod <[email-masked]>
Date: Mon, 27 Apr 2009 11:48:10 -0700

On Fri, Apr 24, 2009 at 1:10 AM, Ian Hickson <[email-masked]> wrote:

> mess it makes.

Not one of the things you listed is a networking protocol. CGI is the
closest thing to what we are talking about, and actually I see very, very
few hand-written CGI parsers. In fact, I'd venture that only a tiny
percentage of all "inexperienced" web programmers know that CGI exists. The
vast majority of them know about PHP or ASP and depend on those tools to
handle CGI (or server-internal equivalent).

That's the right model for network server software development. Let
security-aware experts handle the networking interface. Let them simplify
the protocol to simple parameter values or global variables. The vast
majority of people should understand the protocol at the wire-trace level
but they don't need to implement it.

 Paul Prescod

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 28 Apr 2009 12:03:11 +1000

> complexity of the server-side implementations.

Would it be sufficient to allow optional support of complex features.
So a server could implement a either a simple core of websocket or
a richer more complex feature set?

Also, you have argued against additional frame-type that could better
support complex behaviour on the grounds that the base frame types
can carry that complex protocol with assumptions.   If a mime-encapsulating
frame type is not worth a dedicated frame-type byte, then what
kinds of extensions do you see additional frame-type being defined for?

> version of the protocol, etc.

Welcome to the wonderful world of web protocols!

> Server components only have to deal with the 

I do not think this is generally true.

Server that will implement the websocket protocol are more than likely
going to be done by entirely different sets of developers than those
that write the javascript content that is served from them.

More over, the javascript served will probably be from 2, 3 or even
more distinct sets of developers as frameworks, mashups and other
such things will bring together the work of many into a single page.

There is also the likely hood of more and more cross-site support
and websockets will have to support cross site in some way, so a server
may receive connections from code it didn't actually serve.

Furthermore, intermediary proxy's etc. may alter what is sent/received.
Even if the initial proxies/firewalls don't,  I'm sure somebody will
develop some smart websocket aware proxy that does some

So Server components also have to deal wit non-conforming clients
sending back garbage etc. etc.

> for handling content sent by the current client API.

I think the specification should entirely define the wire protocol without
any assumptions about who/what/where is implementing the client or the
server.    If we wait for non-js-in-browser clients before fully specifying
the server side of the protocol, then we have a chicken and the egg problem.

cheers