Subject: Re: [hybi] Requirement: WebSocket HTTP coexistence (was: Requirement for Maciej security issue)

From: Greg Wilkins <[email-masked]>
Date: Mon, 01 Mar 2010 09:09:40 +0100

Ian Hickson wrote:

> An HTTP stack's connection and IO layers are actually somewhat unlikely to 
> be appropriate for Web Socket, since HTTP is not full-duplex.

HTTP at a IO level is full duplex - or at least frequently implemented
that way. Eg 102 processing responses can be sent while the body of
a request is being received.

Anyway, this is a pretty meaningless debate.    Sure some clients
are not going to reuse HTTP client code.    But some are.

In Jetty, our HTTP client and HTTP server share about 75% of
their code base.   Websockets are now supported as part of
the servers ability to handle Upgrade as per RFC2616, and the
resulting endpoint reuses all the async IO layer of Jetty.

When we do our websocket client, I expect that it will
take a similar approach - because while a good websocket
connection will start with an Upgrade  request and 101
response, I fully expect that we will need to handle
"bad" responses like 403's and 500's.   I don't want
to have to rewrite that handling.

So the point is - some want to reuse code and some
don't.   We need a spec that makes either approach
possible and practical.

cheers

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 01 Mar 2010 00:13:15 -0800

On Feb 28, 2010, at 11:26 PM, Greg Wilkins wrote:

>
> All,
>
> While this thread appears a little unproductive (as I'm not sure
> establishing who has the best appreciation of HTTP history is
> a milestone for the WG), I actually think there are some
> green shoots.
>
> It's really great that Ian is now talking about "we" the working
> group and acknowledging that we are in a process that might
> add some more features to the spec.
>
> Since we are in the requirements phase of the working group,
> I think we all should look at the points being raised here
> and see if we can formulate them as requirements on the specification.
>
> eg - we all kind of agree that good error handling is needed
> in the protocol.... but can we agree that error handling
> includes differentiating orderly/idle/failure closes of
> connections?  We should write up the requirements for error handling!

The most basic error-handling requirement should be that behavior in  
the face of any error condition must be well-defined.

A requirement to report specific conditions (error or otherwise) would  
be separate. I think as far as differentiating orderly/idle/failure  
closes, I'd need to hear more about what counts as what. An idle close  
by your opposite endpoint could presumably just be an orderly close.  
So I assume idle closes worth distinguishing would be by an  
intermediary. Are those actually distinguishable from failure?

>
> eg - there is some consensus that compression should be
> supported as an option .  Is that something
> that we can capture as a requirement?

I think Ian's position was that compression could be added as an  
option in a future version of the protocol. (I personally have no  
opinion, though I would be inclined to say let's not add it until we  
know it's actually needed - see <http://c2.com/xp/YouArentGonnaNeedIt.html 
 >).

>
> Also, we all appear to agree that the resulting protocol will
> support layers... a base framing layer with things like
> content-types, meta-data, fragmentation, multiplexing, etc.
> done in higher layers.      A fundamental question is - are
> these higher layers something for this WG or not?    I would
> like to think yes, because we can't design a framing transport
> in a total vacuum, nor do we wish to encourage 20 different
> meta-data layers etc.   The SPDY spec appears able to
> differentiate itself into a framing layer and a services layer,
> so perhaps we can follow that approach?

I don't think we are chartered to define protocols that run on top of  
the WebSocket protocol, in addition to the WebSocket protocol itself.

Note: I think some of those features could reasonably added to the  
base protocol, but perhaps not in v1.

Regards,
Maciej

>
>
> cheers
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Ian Hickson wrote:
>> On Sun, 28 Feb 2010, Jamie Lokier wrote:
>>>> HTTP is hugely complicated compared to WebSockets. IMHO that's a  
>>>> bug,
>>>> not a feature. By making WebSockets trivial to implement, we enable
>>>> these "quite creative people" to write their own servers.
>>> However, please take a quick look at HTTP's history, because the  
>>> same
>>> will probably occur to WebSocket.
>>
>> We (as the working group) decide whether it happens or not. If we  
>> avoid
>> adding features like content negotiation that are so complicated that
>> hardly anybody ends up using them, if we avoid adding five ways to  
>> encode
>> frames, if we avoid defining complicated header syntaxes like  
>> continuation
>> lines, if we define error-handling behaviour up front, if we avoid  
>> leaving
>> things as basic as what character encoding to use undefined, if we  
>> avoid
>> making our initial protocol non-extensible, in short, if we learn  
>> from the
>> mistakes that the HTTP working group(s) have made over the years,  
>> we can
>> keep Web Socket simple and it _never_ needs to get complicated.
>>
>> So yes, I'm quite familiar with HTTP's history. I'm also quite  
>> confident
>> that the same fate does not need to befall Web Sockets. We don't  
>> need to
>> put multiplexing in the base protocol. We don't need to put metadata
>> mechanisms in the base protocol. We can make compression an optional
>> server-opt-in feature in the second version that has just one  
>> algorithm
>> and that isn't required for simple servers. We can avoid designing
>> theoretical Architectures like REST and just provide trivial tools on
>> which people can build their applications to whatever level of  
>> complexity
>> they like.
>>
>>
>>> I also see, on embedded systems lists, people asking where they  
>>> can get
>>> a small HTTP server to do this, that or the other.  It never  
>>> occurs to
>>> them to just write one (except in one case I can think of, where the
>>> device's badly written HTTP server for diagnostics was the reason it
>>> kept crashing.)  Even though it's actually easy to write a  
>>> conforming
>>> HTTP/0.9 server.
>>
>> People don't know about 0.9; when they think of HTTP they think of  
>> 1.1,
>> and I think it's quite reasonable to not want to implement an HTTP  
>> 1.1
>> server. If we design Web Sockets right, we won't have that problem.
>>
>>
>>> I think the same will happen with WebSocket: Simple at first, but  
>>> before
>>> you know it, it'll have evolved - and the web will be full of dirty
>>> workarounds for buggy clients and servers - just like what  
>>> happened with
>>> HTTP.
>>
>> The reason it happened with HTTP is the same reason it happened  
>> with HTML
>> and CSS -- HTTP didn't define error handling behaviour, so when a  
>> peer did
>> the wrong thing, there was no rule saying what you had to do in  
>> response,
>> and whatever the dominant server or client behaviour was ended up  
>> being
>> the de-facto standard. If we define error handling rules so that  
>> there's
>> no sequence of bytes for which the behaviour is undefined, we side- 
>> step
>> this problem completely.
>>
>>
>>>> For small-scale operations, there's really no need for things to be
>>>> particularly complicated. Sure, if you have hundreds, thousands,
>>>> millions, or billions of users then it is hard work -- and the
>>>> protocol's complexity pales in comparison to the scaling issues.  
>>>> But
>>>> when there are no scaling issues, when you have four users  
>>>> _total_, it
>>>> doesn't have to be hard and the protocol _can_ be a significant
>>>> burden.
>>> +1, I agree with the general sentiment.  But I think it's doomed to
>>> fail.  Especially if the attack-blocking strategies are included,  
>>> it's
>>> simply too much for many programmers at that point to write their  
>>> own.
>>
>> If we don't manage it, then fair enough, but I think giving up  
>> before we
>> try is too pessimistic for my tastes.
>>
>>
>>> Let's put it this way: If plain sockets were perceived as easy to
>>> program, why are there people considering using WebSockets for
>>> application-to-application communications (no browser) - instead  
>>> of just
>>> using plain sockets?  Even though plain sockets are obviously much  
>>> less
>>> work than do-it-yourself WebSockets?
>>
>> That's what I've been asking! The answer I've gotten has been "we  
>> don't
>> expect the servers to provide a TCP socket solution, but they'll  
>> provide
>> one for their scripts running in Web browsers so at least we'll be  
>> able to
>> reuse that".
>>
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Julian Reschke <[email-masked]>
Date: Mon, 01 Mar 2010 09:39:37 +0100

On 28.02.2010 23:18, Ian Hickson wrote:
> ...
> making our initial protocol non-extensible, in short, if we learn from the
> ...

Sorry? HTTP appears to be very extensible to me.

Best regards, Julian

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 1 Mar 2010 08:53:36 +0000

> base protocol, but perhaps not in v1.

I think there are some aspects of framing that are difficult to put in
a higher layer without making inefficient use of the lower layer.  We
should work out exactly what the minimum capability needed from the
lower layer actually is, without making it so minimal that it causes
gross inefficiency.

Specifically, distinguishing parts of split messages (a higher layer
concept), because that affects the delivery timing (whether to delay
for more, or forward immediately) done by an agent that's only aware
of basic frames/messages (a lower layer concept).  The concept needing
to be passed down is a flag (maybe two) influencing delivery
buffering/timing.  Without it, messages are either delayed for a long
time, or forwarded too quickly which paradoxically causes TCP to
introduce quarter-second delays all over the place due to partial
segments.

-- Jamie

---

From: Ian Hickson <[email-masked]>
Date: Mon, 1 Mar 2010 08:59:26 +0000 (UTC)

> Sorry? HTTP appears to be very extensible to me.

Tim's initial implementation (pre-0.9, though often referred to as 0.9) 
didn't have response headers or any way to indicate metadata with a 
response. That's what I was referring to.

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

---

From: Ian Hickson <[email-masked]>
Date: Mon, 1 Mar 2010 09:06:10 +0000 (UTC)

> Tim's initial implementation (pre-0.9, though often referred to as 0.9) 

Actually my bad, what I described is indeed 0.9, not pre-0.9. My 
apologies.

> response. That's what I was referring to.

This still holds, however. HTTP 0.9, as originally designed, had no 
response metadata, it could only carry HTML with all metadata in the 
actual file itself. (I wouldn't be surprised if this is the original 
reason for why we have to do so much sniffing these days.)

---

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 01 Mar 2010 10:28:08 +0100

> reason for why we have to do so much sniffing these days.)

 From what I read about it it is. It's also the reason <plaintext> still  
exists.

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 01 Mar 2010 10:54:10 +0100

> Actually my bad, what I described is indeed 0.9, not pre-0.9. My

I find this *very* misleading. We are discussing protocol design in the 
context of the IETF. The IETF has taken 0.9 as input, and came up with 
1.0, which is *very* extensible.

Maybe a lesson for this WG?

Best regards, Julian

---

From: Ian Hickson <[email-masked]>
Date: Mon, 1 Mar 2010 10:11:04 +0000 (UTC)

On Mon, 1 Mar 2010, Julian Reschke wrote:
> context of the IETF. The IETF has taken 0.9 as input, and came up with 1.0,
> which is *very* extensible.

...and which broke backwards-compatibility with legacy clients at the 
time.

> Maybe a lesson for this WG?

I agree that we can learn from that, though maybe not about what we should 
learn. I think it teaches us to make sure to make our protocol have 
designed extension mechanisms for future versions that are 
forwards-compatible, that we should keep our protocol very simple, even in 
an "official" version, and we should ensure that we never break backwards- 
compatibility with legacy deployed services.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 01 Mar 2010 11:29:53 +0100

> ...and which broke backwards-compatibility with legacy clients at the

Was this a problem in practice? I honestly don't recall.

> compatibility with legacy deployed services.

Hm, no. Break backwards compatibility if it brings clear benefits, and 
the damage is not too big.

Best regards, Julian

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 01 Mar 2010 11:39:51 +0100

> compatibility with legacy deployed services.

Unless those legacy deployed services are using an insecure handshake
that we have to change anyway.

Seriously, I think that any services built on the current rollout
of websocket have to know that it is very early days... and that
they can expect at least one phase of breakage before a standard
is agreed.

cheers

---

From: Dave Cridland <[email-masked]>
Date: Mon, 01 Mar 2010 11:10:09 +0000

On Mon Mar  1 03:09:03 2010, Jamie Lokier wrote:
>     Keepalive messages are sent and received every 30 seconds, on  
> each
>     connection.  Each keepalive causes a TCP ACK.

That's deeply unrealistic now, thank heavens.

2 minutes is much more sane, and it's increasing rapidly, as  
protocols other than HTTP have reached the public demand stages -  
XMPP, IMAP, etc all benefit from long-lived, dormant connections.

So keepalives should, in principle, gradually fade away as reasonable  
network behaviour takes over.

This behavioural flux, though, is an excellent argument for putting  
keepalive behaviour into the core, as the people designing the  
frameworks are likely to have good ideas of the defaults, and  
keepalive frequencies will need to be controlled per-deployment,  
typically, rather than per-application.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: <[email-masked]>
Date: Mon, 1 Mar 2010 14:36:16 +0100

Hi,

I haven't followed the discussions very deeply but the keepalive issue caught my eye.

Jamie Lokier wrote:
>
>Problems:
>
>On the mobile phone, it's quite power hungry.  Waking up the 
>packet radio is one of the major power consumers.  The number 
>of _bytes_ isn't very important; the number of packets is.
>

That's very true. Wide area cellular radios (WCDMA, HSPA, LTE, CDMA-2000, WiMAX) all have pretty good power-save modes, but sending/receiving a packet always requires to activate the radio, and after that it stays up for a while (from a couple of seconds upto 30). So, with any cellular wireless interfaces a keepalive rate of 1/30 sec. is really bad for the battery. In practice you could only run such an application for a few hours before you have to recharge. Keepalive rate of 1/10 minutes or so is still tolerable, the users may not notice anything exceptional with how fast the battery runs out. Things are improving with radios and batteries, but this will still be a major constraint for a next few years.

If WebSocket connection is mainly used for apps where user is somehow interactive and closes the app/connection, this is not so bad. But if the intention is that some background widget etc. uses this all the time, then things may get infeasible. Users will not use such widgets when they notice that they have to charge the device constantly. 

How large the packets are may not matter that much, but actually there are some mainstream radio systems (WCDMA-based), where sending very small IP packets (~100-200 bytes) is possible without reserving a dedicated channel, thus requiring also less radio signaling and power. So it would be very good if the keepalive packet were as small as possible. (Full HTTP request is already a problem, but since WebSocket is different I hope it's also more compact in this respect.) So keep this in mind too.

>At home (with 3 people and lots of browser tabs), it's a lot 
>of continuous traffic, and we haven't counted actual messages, 
>just idle keepalives.
>
>If we decrease the number of tabs in the desktop browsers at 
>home to 10 per desktop, it's acceptable.  But that shouldn't 
>be necessary.
>

This is a different topic, but if IPv4 address scarcity eventually gets really bad (and IPv6 does not get deployed fast enough to help), keeping a large number of open TCP connections per subscriber/home may become costly too for the ISPs, since each requires a mapping in their big NAT box. 

>If we increased the keepalive interval to 1 minute (which is 
>too long for some networks), these numbers still don't look good.
>

True.

>The issue here is entirely down to being unable to share 
>keepalives across multiple WebSocket instances.

That would be useful. Having said that, even if each instance uses a separate keepalive, an implementation may still be able to "synchronize" them so that they happen at the same time. That would help with waking up the radio to some extent too. But even better would be if a single keepalive could be used. 

Here's my wishlist for the keepalive:
- Make it as small as possible in terms of bytes.
- Provide a way how the client (and the server?) can determine what the required rate is so that an optimal rate [as low as possible vs. keep all the boxes in the middle happy] can be used. 
- If possible, allow sharing keepalives. (Don't know if it's feasible in this context. I understand this also requires sharing a TCP connection, at least when NAT/FW-type of middleboxes are concerned.)
- If possible, allow switching to some other protocol mechanism for keepalive purposes, say XMPP. (This might be out-of-scope for WebSocket work but in theory this could be possible.)

I guess now it would be a good time for me to review what the draft actually says about keepalives and comment on that....

>-- Jamie

Regards,
	Markus

---

From: "Alexander Philippou" <[email-masked]>
Date: Mon, 1 Mar 2010 14:57:47 +0200

> If we avoid adding features like content negotiation that are so complicated that hardly anybody ends up using them

In Web services, content negotiation (exchanging headers such as Accept and Content-Type) is used to support multiple SOAP/REST message encodings and compression algorithms on a single service endpoint so that responses are encoded depending on what each particular client supports/prefers.

Web Socket is superior to HTTP for use by Web services. It would be sufficient to support content negotiation on a per-connection basis during the initial handshake (instead of on a per-message basis as per HTTP) for Web Socket to be used by Web services.

Can we use the initial HTTP handshake for content negotiation?

Alexander Philippou

---

From: Mridul Muralidharan <[email-masked]>
Date: Mon, 1 Mar 2010 20:24:42 +0530 (IST)

I hope you are not serious with this reasoning !
Server side notifications would be the compelling usecase for websockets - everything else is already handled by existing protocols.

Regards,
Mridul

----- Original Message ----
> From: Ian Hickson <[email-masked]>
> To: Jamie Lokier <[email-masked]>
> Cc: Server-Initiated HTTP <[email-masked]>
> Sent: Mon, 1 March, 2010 8:56:13 AM
> Subject: Re: [hybi] Various comments on recent threads
> 
> On Mon, 1 Mar 2010, Jamie Lokier wrote:
> > Ian Hickson wrote:
> > > > 3. There are no server initiated events, which skips the main value of 
> > > > web sockets (point #1).
> > > 
> > > That isn't the main value, IMHO.
> > 
> > If that's not the main value, what is?
> 
> The persistent connection. For example, a multiplayer game can have a 
> single connection for each user, such that whenever a user does anything 
> it can determine which user sent the message trivially, and it can notify 
> all the other users. Consider a tic-tac-toe game: there's nothing 
> happening except when the user sends a message. It's orders of magnitude 
> easier to implement a tic-tac-toe server with Web Sockets than over HTTP. 
> The same applies to many other scenarios; chat, any turn-based game, etc.
> 
> In any case, it's trivial to add a timeout to a select() call and send 
> messages in response to something other than an incoming message, so I 
> really don't think that's a real concern.
> 
> -- 

      Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 01 Mar 2010 19:36:30 +0200

Hi,

thank for the discussion, feedbacks and comments
it seems to me that there is an acceptable consensus on the following 
requirements

Req. X   The WebSocket protocol MUST allow HTTP and WebSocket 
connections to be served from the same port.
               Consideration MUST be given
               * to provide WebSocket services via  modules that plug in 
to existing web infrastructure.
               * to making it possible and practical to implement 
standalone implementations of the protocol
                  without requiring a fully conforming HTTP  implementation.

Reason: Some server developers would like to integrate WebSocket support 
into existing HTTP servers.
              In addition, the default HTTP and HTTPS ports are ofter 
favoured for traffic that has to go through a firewall,
              so service providers will likely want to be able to use 
WebSocket over ports 80 and 443, even when running a We server
              on the same host. However there could be scenarios where 
it is not opportune or possible to setup a proxy on the same
              HTTP server.

Req. Y   When sharing host and "well known" port with HTTP, the 
WebSocket protocol MUST be HTTP compatible until both ends have
              established the WebSocket protocol.

Reason: when operating on the standard HTTP ports, existing web 
infrastructure may handle according to existing standards prior to
               the establishment of the new protocol.

Req. Z   The protocol SHOULD make it possible and practical to reuse 
existing HTTP components where appropriate.

Reason:  the re-usage of existing well-debugged software decreases the 
number of implementation errors as well as the possibility to
               introduce security holes especially and at the same time 
speed up the development especially when  the Web Socket server
               is implemented as modules that plug in to existing 
popular Web servers

any objection to have them inserted in the draft instead of

    REQ. 6:  The Web Socket Protocol MUST be designed in such a way that
                  its servers can share a port with HTTP servers, as by 
default the
                  Web Socket Protocol uses port 80 for regular Web Socket
                  connections and port 443 for Web Socket connection 
tunnelled over  TLS.

cheers
Sal

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 01 Mar 2010 18:55:47 +0100

Maciej Stachowiak wrote:
> by your opposite endpoint could presumably just be an orderly close. So
> I assume idle closes worth distinguishing would be by an intermediary.
> Are those actually distinguishable from failure?

I think idle close where the browser/server/network decides to close
the connection because it is idle, is very different to an application
initiated close, where the application has decided that a connection
to the server is no longer needed.  Both are very different to
the server closing the connection because of some protocol
violation or a too large a message.

For a network idle close, an app is likely to want to
immediately create a new websocket connection.

For a close during handshake the app is likely
to want to retry, but after a backed off delay to
prevent busy looping.

For an application initiated close, the app is
not likely to reconnect at all.

I've just blogged about these kinds of use case, which for
IETF IP reasons I'll paste the  badly formatted
text of it below:  Sorry for the product plugs.

cheers

http://blogs.webtide.com/gregw/entry/websocket_chat
-------------------------------------------------------------

The websocket protocol has been touted as a great leap forward for bidirectional web applications like chat, promising a new era of simple comet applications. Unfortunately there
is no such thing as a silver bullet and this blog will walk through a simple chat room to see where websocket does and does not help with comet applications. In a websocket world,
there is even more need for frameworks like cometd.

Simple Chat

A chat is the "helloworld" application of web-2.0 and a simple websocket chat room is included with the jetty-7 which now supports websockets. The source of the simple chat can be
seen in svn for the client side and server side. The key part of the client side is to establish a WebSocket connection:

        join: function(name) {
          this._username=name;
          var location = document.location.toString().replace('http:','ws:');
          this._ws=new WebSocket(location);
          this._ws.onopen=this._onopen;
          this._ws.onmessage=this._onmessage;
          this._ws.onclose=this._onclose;
        },

It is then possible for the client to send a chat message to the server:

        _send: function(user,message){
          user=user.replace(':','_');
          if (this._ws)
            this._ws.send(user+':'+message);
        },

and to receive a chat message from the server and to display it:

        _onmessage: function(m) {
          if (m.data){
            var c=m.data.indexOf(':');
            var from=m.data.substring(0,c).replace('<','<').replace('>','>');
            var text=m.data.substring(c+1).replace('<','<').replace('>','>');

            var chat=$('chat');
            var spanFrom = document.createElement('span');
            spanFrom.className='from';
            spanFrom.innerHTML=from+': ';
            var spanText = document.createElement('span');
            spanText.className='text';
            spanText.innerHTML=text;
            var lineBreak = document.createElement('br');
            chat.appendChild(spanFrom);
            chat.appendChild(spanText);
            chat.appendChild(lineBreak);
            chat.scrollTop = chat.scrollHeight - chat.clientHeight;
          }
        },

For the server side, we simply accept incoming connections as members:

        public void onConnect(Outbound outbound)
        {
            _outbound=outbound;
            _members.add(this);
        }

and then for all messages received, we send them to all members:

        public void onMessage(byte frame, String data)
        {
            for (ChatWebSocket member : _members)
            {
                try
                {
                    member._outbound.sendMessage(frame,data);
                }
                catch(IOException e)
                {
                    Log.warn(e);
                }
            }
        }

So we are done right?  We have a working chat room - let's deploy it and we'll be the next google gchat!! Unfortunately reality is not that simple and this chat room is a long way
short of the kinds of functionality that expect from a chat room - even a simple one.
Not So Simple Chat
On Close?

With a chat room, the standard use-case is that once you establish your presence in the room and it remains until you explicitly leave the room.  In the context of webchat, that
means that  you can send receive a chat message until you close the browser or  navigate away from the page.   Unfortunately the simple chat example does not implement this
semantic because the websocket protocol allows for an idle timeout of the connection. So if nothing is said in the chat room for a short while then the websocket connection will be
closed, either by the client, the server or even and intermediary. The application will be notified of this event by the onClose method being called.

So how should the chat room handle onClose?  The obvious thing to do is for the client to simply call join again and open a new connection back to the server:

        _onclose: function() {
          this._ws=null;
          this.join(this.username);
        }

This indeed maintains the user's presence in the chat room, but is far from an ideal solution since every few idle minutes the user will leave the room and rejoin. For the short
period between connections, they will miss any messages sent and will not be able to send any chat themselves.
Keep Alives

In order to maintain presence, the chat application can send keep-alive messages on the websocket to prevent it being closed due to an idle timeout.  However, the application has
no idea at all about what the idle timeout are, so it will have to pick some arbitrary frequent period (eg 30s) to send keep-alives and hope that is less than any idle timeout on
the path (more or less as long-polling does now). Ideally a future version of websocket will support timeout discovery, so it can either tell the application the period for
keep-alive messages or it could even send the keep alives on behalf of the application.

Unfortunately keep-alives don't avoid the need for onClose to initiate new Websockets, because the internet is not a perfect place and specially with wifi and mobile clients,
sometimes connections just drop.  It is a standard part of HTTP that if a connection closes while being used, the GET requests are retried on new connections, so users are mostly
insulated from transient connection failures.  A websocket chat room needs to work with the same assumption and even with keep-alives, it needs to be prepared to reopen a
connection when onClose is called.
Queues

With keep alives, the websocket chat connection should be mostly be a long lived entity, with only the occasional reconnect due to transient network problems or server restarts.
Occasional loss of presence might not been seen to be a problem, unless you're the dude that just typed a long chat message on the tiny keyboard of your vodafone360 app or instead
of chat you are playing on chess.com and you don't want to abandon a game due to transient network issues.  So for any reasonable level of quality of service, the application is
going to need to "pave over" any small gaps in connectivity by providing some kind of message queue in both client and server.  If a message is sent during the period of time that
there is no websocket connection, it needs to be queued until such time as the new connection is established.
Timeouts

Unfortunately, some failures are not transient and sometimes a new connection will not be established. We can't allow queues to grow for ever and to pretend that a user is present
long after their connection is gone. Thus both ends of the chat application will also need timeouts and user will not be seen to have left the chat room until they have no
connection for the period of the timeout or until an explicit leaving message is received.

Ideally a future version of websocket will support an orderly close message so the application can distinguish between a network failure (and keep the user's presence for a time)
and an orderly close as the user leaves the page (and remove the user's present).
Message Retries

Even with message queues, there is a race condition that makes it difficult to completely close the gaps between connections. If the onClose method is called very soon after a
message is sent, then the application has no way to know if that close happened before or after the message was delivered. If quality of service is important, then the application
currently has not option but to have some kind of per message or periodic acknowledgement of message delivery. Ideally a future version of websocket will support orderly close, so
that delivery can be known for non failed connections and a complication of acknowledgements can be avoided unless the highest quality of service is required.
Backoff

With onClose handling, keep-alives, message queues, timeouts and retries, we finally will have a chat room that can maintain a users presence while they remain on the web page.
But unfortunately the chat room is still not complete, because it needs to handle errors and non transient failures. Some of the circumstances that need to be avoided include:

    * If the chat server is shut down, the client application is notified of this simply by a call to onClose rather than an onOpen call. In this case, onClose should not just
reopen the connection as a 100% CPU busy loop with result.  Instead the chat application has to infer that there was a connection problem and to at least pause a short while before
trying again - potentially with a retry backoff algorithm to reduce retries over time. Ideally a future version of websocket will allow more access to connection errors, as the
handling of no-route-to-host may be entirely different to handling of a 401 unauthorized response from the server.
    * If the user types a large chat message, then the websocket frame sent may exceed some resource level on the client, server or intermediary. Currently the websocket response
to such resource issues is to simply close the connection.  Unfortunately for the chat application, this may look like a transient network failure (coming after a successful onOpen
call), so it may just reopen the connection and naively retry sending the message, which will again exceed the max message size and we can lather, rinse and repeat!  Again it is
important that any automatic retries performed by the application will be limited by a backoff timeout  and/or max retries.   Ideally a future version of websocket will be able to
send an error status as something distinct from a network failure or idle timeout, so the application will know not to retry errors.

Does it have to be so hard?

The above scenario is not the only way that a robust chat room could be developed. With some compromises on quality of service and some good user interface design, it would
certainly be possible to build a chat room with less complex usage of a WebSocket.  However, the design decisions represented by the above scenario are not unreasonable even for
chat and certainly are applicable to applications needing a better QoS that most chat rooms.

What this blog illustrates is that there is no silver bullet and that WebSocket will not solve many of the complexities that need to be addressed when developing robust comet web
applications. Hopefully some features such as keep alives, timeout negotiation, orderly close and error notification can be build into a future version of websocket, but it is not
the role of websocket to provide the more advanced handling of queues, timeouts, reconnections, retries and backoffs.   If you wish to have a high quality of service, then either
your application or the framework that it uses will need to deal with these features.
Cometd with Websocket

Cometd version 2 will soon be released with support for websocket as an alternative transport to the currently supported JSON long polling and JSONP callback polling. Cometd
supports all the  features discussed in this blog and makes them available transparently to browsers with or without websocket support.  We are hopeful that websocket usage will be
able to give us even better throughput and latency for cometd than the already impressive results achieved with long polling.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 1 Mar 2010 09:56:33 -0800

I think that Propsed reqs X,Y,Z are much clearer than the current Req 6.
No objection here.
-=R

On Mon, Mar 1, 2010 at 9:36 AM, Salvatore Loreto <
[email-masked]> wrote:

> Req. X   The WebSocket protocol MUST allow HTTP and WebSocket connections
> to be served from the same port.
>
>              * to provide WebSocket services via  modules that plug in to
> existing web infrastructure.
>              * to making it possible and practical to implement standalone
> implementations of the protocol
>             on the same host. However there could be scenarios where it is
> not opportune or possible to setup a proxy on the same
>             HTTP server.
>
>
>
>
> Req. Y   When sharing host and "well known" port with HTTP, the WebSocket
> protocol MUST be HTTP compatible until both ends have
>              introduce security holes especially and at the same time speed
> up the development especially when  the Web Socket server
>              is implemented as modules that plug in to existing popular Web
> servers
>
>
>

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 01 Mar 2010 19:58:06 +0200

Hi,

I want take the chance to remember that HyBi has as a goal to submit
a document as a working group item describing the Design Space 
characterization

at the BoF we discussed this: 
http://www.ietf.org/id/draft-loreto-design-space-bidirectional-00.txt

so any initiative to investigate the Design Space (and also take on the 
draft editorship) are very well welcome.

cheers
Sal

On 02/28/2010 09:34 PM, Maciej Stachowiak wrote:
> On Feb 28, 2010, at 11:18 AM, Tim Bray wrote:
>>
>> I was thinking that I should put together a standalone client & 
>> server in Ruby trying to use as much of Net::HTTP and Rack 
>> respectively as possible, to explore how much re-use is possible.
>> Two questions:
>> - has anyone done this already?
>> - Is this so far outside the design space as to be silly?
>> It'd only be a few hours work I think.
>>
> Server: Definitely not outside of the design space. Interesting questions:
> - What things are unusually hard to implement?
> - Does it seem harder or simpler to make a standalone implementation 
> this way, compared to coding directly against the wire protocol?
>
> Client: Not sure if any practical reuse of HTTP is possible, but it 
> would be interesting to find out.
>
>
> Regards,
> Maciej
>>
>> - Tim
>>
>>
>>> On Feb 28, 2010 10:37 AM, "Maciej Stachowiak" <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>>
>>> On Feb 27, 2010, at 10:25 PM, Greg Wilkins wrote:
>>>
>>> >
>>> >
>>> > Jamie Lokier wrote:
>>> >>
>>> >> Basically I see ...
>>>
>>> It's entirely possible to create a version of this protocol that is 
>>> *not* friendly to the standalone use case. If we designed the 
>>> protocol solely to work well as part of an HTTP server, it's 
>>> actually pretty likely that we'd make it needlessly complicated for 
>>> authors of standalone servers. In particular, your suggestion that 
>>> "it is easier to reuse an existing HTTP stack" is one that I think 
>>> standalone server authors would probably not agree with.
>>>
>>>
>>> > There is a specific requirement we are trying to capture. Some on
>>> > this list want the handshake...
>>>
>>> I don't think that's all of what we are trying to capture. We'd like 
>>> it to be reasonable to implement a standalone server, regardless of 
>>> whether the difficulties are imposed by HTTP-related processing or 
>>> something else. For example, if the message framing was unduly 
>>> elaborate, then I'd say we are failing the requirements for 
>>> standalone servers.
>>>
>>>
>>> >
>>> >>  2. Servers which serve HTTP and WebSocket on the same port must be
>>> >>     fully HTTP compat...
>>>
>>> I think this captures the combo server requirements reasonably well, 
>>> but is not so good at capturing the standalone server requirements. 
>>> I think we should listen to those who have implemented or plan to 
>>> implement a standalone server with regards to those.
>>>
>>> Regards,
>>> Maciej
>>>
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.o...
>>>

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 01 Mar 2010 10:18:19 -0800

> immediately create a new websocket connection.

That seems like a reasonable use case, I'm just not sure if it is  
possible to distinguish idle close by an intermediary from random  
network failure that breaks the connection. At least for  
intermediaries that can pass the protocol through without being  
modified (e.g. HTTPS or SOCKS proxies).

Regards,
Maciej

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 01 Mar 2010 19:31:50 +0100

Maciej Stachowiak wrote:

> network failure that breaks the connection. At least for intermediaries
> that can pass the protocol through without being modified (e.g. HTTPS or
> SOCKS proxies).

I don't think we can tell the difference - unless we do some heuristic/statistical
analysis to see if a certain path always closes after a particular period of idleness.
Some imples might do this if other timeouts become discoverable... but you'd not
want to require such analysis.

Luckily the handling for a network failure and an idle timeout in an intermediary
will be pretty much the same - immediately reopen the connection.

If the reopen then closes before handshake completes, that will tell the
app that it was a network failure and not an idle timeout.

cheers

---

From: Justin Erenkrantz <[email-masked]>
Date: Mon, 1 Mar 2010 18:46:50 +0000

> I think that Propsed reqs X,Y,Z are much clearer than the current Req 6.

Ditto...  -- justin

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 01 Mar 2010 11:48:18 -0800

On Mar 1, 2010, at 10:31 AM, Greg Wilkins wrote:

>> intermediaries

So it sounds like the cases to distinguish are "clean close" vs  
"unexpected close". It sounds like that is feasible to do with  
explicit close messages.

Regards,
Maciej

---

From: Ian Hickson <[email-masked]>
Date: Mon, 1 Mar 2010 22:14:31 +0000 (UTC)

On Mon, 1 Mar 2010, Alexander Philippou wrote:
> >
> > If we avoid adding features like content negotiation that are so 
> > complicated that hardly anybody ends up using them
> 
> In Web services, content negotiation (exchanging headers such as Accept 
> and Content-Type) is used to support multiple SOAP/REST message 
> encodings and compression algorithms on a single service endpoint so 
> that responses are encoded depending on what each particular client 
> supports/prefers.
> 
> Web Socket is superior to HTTP for use by Web services. It would be 
> sufficient to support content negotiation on a per-connection basis 
> during the initial handshake (instead of on a per-message basis as per 
> HTTP) for Web Socket to be used by Web services.
> 

Could you elaborate on what the concrete use case is?

---

From: Ian Hickson <[email-masked]>
Date: Mon, 1 Mar 2010 22:20:44 +0000 (UTC)

On Mon, 1 Mar 2010, [email-masked] wrote:
> 
> If WebSocket connection is mainly used for apps where user is somehow 
> interactive and closes the app/connection, this is not so bad. But if 
> the intention is that some background widget etc. uses this all the 
> time, then things may get infeasible. Users will not use such widgets 
> when they notice that they have to charge the device constantly.

For server-push updates, the server-sent events feature:

   http://dev.w3.org/html5/eventsource/

...is designed to be implementable in such a way that handsets can offload 
the keepalive responsibility to the cell network infrastructure, to avoid 
this problem. I wouldn't recommend using WebSockets for server-push 
updates; when the client isn't sending data, it's best to shut down the 
WebSocket connection altogether.

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 01 Mar 2010 23:57:33 +0100

> WebSocket connection altogether.

Ian,

I had seen this server-sent "feature" some time ago and had erroneously
thought it was some early attempt server push that had been replaced
by websocket.

I find it very very strange that HTML 5 contains two very similar
mechanism.   You'd think that a full duplex mechanism like websocket
could easily handle the simplex needs of server-sent-events.

Note also that I don't see anything in server-sent-events that
will prevent an intermediary caching the content in a way
that will prevent events from being delivered.    I expect
intermediaries will need to be updated to have special case
handling for this content type.  It also appears that it
cannot deliver binary data.

The connectionless push feature would be really worthwhile
to have for full duplex as well as simplex communication, although
the current spec appears to imply this is a proprietary mechanism
rather than an open standard?

Is there much development happening with this feature?

regards

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 01 Mar 2010 15:58:40 -0800

> Is there much development happening with this feature?

WebKit supports EventSource and has for some time. Even in light of  
WebSocket, I believe it is useful because:

1) The half duplex model has less deployment challenge. We know it can  
go through unmodified HTTP proxies and man-in-the-middle pseudo- 
proxies without breaking mysteriously. It's just syntactic sugar on  
top of a streaming GET.

2) This model can plausibly convert to an alternate tunnel for  
notifications, such as SMS to cell phones. There have been proposals  
for how to do this though no formal spec yet. I believe there is  
interest in standards activity in this area.

As for caching, it would be the server's responsibility to ensure that  
its response is not unduly cached, as with XMLHttpRequest-based data  
services. It seems to me this can be achieved with Cache-Control  
headers. Servers need to make the response uncacheable anyway to avoid  
caching at the client.

Regards,
Maciej

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 1 Mar 2010 21:01:56 -0800

On Feb 28, 2010, at 2:18 PM, Ian Hickson wrote:

>>> HTTP is hugely complicated compared to WebSockets. IMHO that's a bug, 
>> However, please take a quick look at HTTP's history, because the same 
> We (as the working group) decide whether it happens or not. If we avoid 
> hardly anybody ends up using them, if we avoid adding five ways to encode 
> frames, if we avoid defining complicated header syntaxes like continuation 
> lines, if we define error-handling behaviour up front, if we avoid leaving 
> things as basic as what character encoding to use undefined, if we avoid 
> mistakes that the HTTP working group(s) have made over the years, we can 
> So yes, I'm quite familiar with HTTP's history.

Apparently not.

HTTP/1.0 had only end-on-close framing before the working group
got involved.  Should we have been happy with a framing
that had no distinction between success and error?  I added
content-length framing because it was a minimal backwards-compatible
way to indicate early-close, enable safe caching, and introduce
keep-alive connections.  However, CL was known at the time to
not be sufficient for dynamic streams, so we also introduced
chunked encoding for 1.1 (when it was first possible to do so),
again in a way that promoted backwards-compatibility.

Those were design choices taken in the context of 1.x compatibility
while HTTPng/MUX was being worked on in parallel.  Do you actually
disagree with those decisions?

Content negotiation is so complicated that hardly anybody uses it?
Get a clue.  Almost all major corporate websites use content negotiation
for the initial selection of language, and more than half of all
Internet sites use it for error messages.  The design came from
CERN libwww, long before the WG was formed, and was intended to
deploy automated user agents in parallel with browsers.  The only
applications that don't support it very well are browsers,
because they couldn't figure out a decent config mechanism and
because the early implementations were stupid (see XMosaic).

As an architectural decision, however, I think content negotiation
was a bad trade-off because the shorter latency of a quick
negotiated response was not worth the negative impacts on
latency due to sending too many request headers, the privacy
concerns of same, and effect of variance on caching.  That is
why I added other ways of doing the same thing (300 and Alternates),
which failed to be picked up by browsers.

HTTP was defined in the ISO-8859-1 character encoding, since 1992.
The fact that it is no longer a suitable default is not HTTP's
problem (UTF-8 did not exist at the time).

Lack of error-handling requirements is because error-handling is
specific to implementation purpose (not protocol) and HTTP is used
by more bizarrely-unique applications than any other application
protocol (not just browsers).  Repeated insistence that such a thing
is an aspect of "good" protocol design does not make it so.

Extensibility (something that HTTP has more of than almost all
other Internet protocols) embodies an inherent trade-off with
multi-organizational trust -- a protocol that can be bent any
which way cannot be trusted as much as a protocol that has
very specific bend points and is amenable to inspection.  One
person's extension is another person's denial of service.

But it is largely a waste of time to tell you any of this.
Go read the early www-talk history.

> I'm also quite confident 
> that the same fate does not need to befall Web Sockets. We don't need to 
> server-opt-in feature in the second version that has just one algorithm 
> which people can build their applications to whatever level of complexity 
> they like.

Yes.  You are happily redesigning TCP-for-the-clueless.  Big deal.
I still don't understand why you don't just implement TLS directly,
especially if the hostname binding to same-origin can be done
in the initial handshake.

HTTP doesn't do this stuff because it won't SCALE, even with the
vastly superior networks today.  It is just a bad idea, in general,
to pretend that N:1 services should involve long-term connections
when N is large.  The only way to avoid that "theoretical" problem
is to go connectionless with some magic congestion-free message
passing protocol that flies through NATs.  I am pretty sure that
will happen shortly after IPv6 is fully deployed.

> I also see, on embedded systems lists, people asking where they can get 
>> a small HTTP server to do this, that or the other.  It never occurs to 
>> kept crashing.)  Even though it's actually easy to write a conforming 
>> HTTP/0.9 server.
> 
> People don't know about 0.9; when they think of HTTP they think of 1.1, 
> and I think it's quite reasonable to not want to implement an HTTP 1.1 
>> I think the same will happen with WebSocket: Simple at first, but before 
>> workarounds for buggy clients and servers - just like what happened with 
>> HTTP.
> 
> The reason it happened with HTTP is the same reason it happened with HTML 
> and CSS -- HTTP didn't define error handling behaviour, so when a peer did 
> the wrong thing, there was no rule saying what you had to do in response, 
> and whatever the dominant server or client behaviour was ended up being 
> the de-facto standard. If we define error handling rules so that there's 
> no sequence of bytes for which the behaviour is undefined, we side-step 
> this problem completely.

HTTP is still trivial.  The spec is not, but the spec's condition is
what happens when there are too many editors that haven't written
their own implementations of the protocol.  Everyone has an opinion
on HTTP.

If you want to learn from HTTP's mistakes, then do so.  Stop parroting
the ignorant assumptions you've heard and actually learn how the Web
works across heterogeneous systems.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 1 Mar 2010 21:32:19 -0800

On Mar 1, 2010, at 1:54 AM, Julian Reschke wrote:
> I find this *very* misleading. We are discussing protocol design in the context of the IETF. The IETF has taken 0.9 as input, and came up with 1.0, which is *very* extensible.

Actually, we didn't even create an IETF working group for HTTP
until December 1994, more than a year after everyone was using
the various bits of "HTTP/1.0" as designed on www-talk and mostly
documented on CERN's website.  The IETF effort was to make a
standard out of what everyone agreed to implement, not just
document every single misfeature found on the Web.

RFC1945 is the subset of HTTP/1.0 implementations in the wild
that actually worked in practice after two years of deployment.

HTTP/1.1 became necessary after it was made clear that 1.0
in its then-current form was unsuitable for standardization.

My preference is that Internet protocols be proven in practice
before anyone tries to claim them as a standard.  Experiments
should be allowed to experiment, and distinct versioning is
necessary to get deployment experience without reducing the
standards process to a bad case of rubber stamping.

....Roy

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 02 Mar 2010 07:41:50 +0100

Maciej Stachowiak wrote:
> go through unmodified HTTP proxies and man-in-the-middle pseudo-proxies
> without breaking mysteriously. It's just syntactic sugar on top of a
> streaming GET.

Does it?   Proxies are under no obligation to pass on even 1 byte
of a response until the very last byte has been received from the
server.   It just so happens that most of them don't buffer
significant amounts of content, so "streaming" push like this
mostly work.  But there is nothing in the standards to prevent
a valid proxy buffering  such streams and there are enough proxies
out there that do so that pure streaming push solutions mostly
need to have a fall back to long polling when the stream does not
work.

Has there been any study to see how well this content
type actually transmits through the internet?

> notifications, such as SMS to cell phones. There have been proposals for
> how to do this though no formal spec yet. I believe there is interest in
> standards activity in this area.

Which is a really good initiative.   If you have any pointers to where
this is taking place, then I'm very interested to know, as I think we
should consider a similar facility for websocket.

As Roy said in his recent post, requiring N connections for N clients
and this applies equally for duplex as for one-way communications.

> headers. Servers need to make the response uncacheable anyway to avoid

Sorry - I meant to say buffering rather than caching (see above).

regards

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 01 Mar 2010 22:57:27 -0800

On Mar 1, 2010, at 10:41 PM, Greg Wilkins wrote:

>> proxies

I'm primarily concerned with whether it breaks in practice, not  
whether a proxy could conform to standards and still break it.

> type actually transmits through the internet?

I'm not aware of any quantitative studies. The best evidence I am  
aware of that it works is the fact that streaming GET (i.e. via  
XMLHttpRequest) is widely used and is not reported to be problematic.  
EventSource behaves identically at the protocol level (other than the  
funny content type).

> should consider a similar facility for websocket.

This was discussed at TPAC 2009 but I do not have pointers handy.

> and this applies equally for duplex as for one-way communications.

EventSource can in theory work with 0 persistent connections, given  
the right kind of way to communicate with the server. But I believe  
there are categories of services where a persistent connection is  
workable and desirable. I expect not every Web site will want to use  
it, but the widespread use of the "long polling" pattern indicates  
demand and willingness to keep connections open for a while.

> Sorry - I meant to say buffering rather than caching (see above).

In that case, I see your point. The best information we have is that  
undue buffering is not widespread. But it's certainly possible. Are  
you aware of any HTTP intermediary software that would buffer an  
uncacheable streaming response indefinitely?

Regards,
Maciej

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 02 Mar 2010 08:30:11 +0100

Maciej Stachowiak wrote:
> I'm primarily concerned with whether it breaks in practice, not whether
> a proxy could conform to standards and still break it. 

I agree that we can't get too hung up about every theoretical
problems that might occur.   But in the case, it is definitely
a real problem - albeit not that common.    Generally I
see that relying on common implementation rather than
standard specification is going to be at best fragile.

> undue buffering is not widespread. But it's certainly possible. Are you
> aware of any HTTP intermediary software that would buffer an uncacheable
> streaming response indefinitely?

I have definitely encountered such proxies in the wild.
In fact for a few years I was living in an apartment block that
provided internet, but they had a transparent proxy that
buffer responses (it could have been squid?) and only flushed on
buffer overflow.

As I was unable to use streaming, I was unable to well support
it and that is one of the reasons it was not maintained and
eventually dropped from the cometd project.

I know that is only anecdotal, but it was frustrating enough
for me to be vary wary of streaming content over protocols
not designed for streaming.

It would be really good if somebody with a widely deployed
push site that supports streaming could comment on any stats
they have about how often they need to fall back to long polling?
My own sites don't even try streaming, so I don't have that info.
Anybody from Google wave here?  what about gchat?

regards

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 02 Mar 2010 17:18:58 +0900

On 2010/03/01 16:19, Maciej Stachowiak wrote:
>
> On Feb 28, 2010, at 8:58 PM, Ian Hickson wrote:

>> I cannot see a sane way to do it. If it's as easy to do in HTTP as in Web
>> Socket, then maybe there isn't a need for this protocol at all. That
>> certainly would make our lives easier.
>
>
> You'd have to encode the full game state in a Cookie. That's simple
> enough for Tic Tac Toe, because the game state is trivial. For a more
> complicated game, or a multiplayer game, not so much. You'd need a
> session cookie that indexes to some persistent state on the server side.
> Coding that would surely be more complicated and would likely require
> some form of framework.

Hello Maciej,

Do you want to say that having to use a framework is a problem? In that 
case, I'd disagree. (If not, then could you explain what your point 
was?) There are dozens of frameworks for HTTP, for all kinds of needs. 
I'd definitely prefer using a good framework (let's say Ruby on Rails or 
some such) to having to code something like Ian's Tic-Tac-Toe server 
(http://damowmow.com/playground/demos/websocket/tic-tac-toe.pl) by hand, 
if that were the alternatives I had.

I think I have said so earlier, but I'd also highly prefer to use a 
server-side framework for WebSockets rather than having to write code 
like the one in the Tic-Tac-Toe examples. Essentially, DRY (don't repeat 
yourself) or DRO (don't repeat others).

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Ian Hickson <[email-masked]>
Date: Tue, 2 Mar 2010 08:26:41 +0000 (UTC)

> yourself) or DRO (don't repeat others).

Nobody is saying that using a framework should be disallowed. Personally, 
I'm interested in designing a protocol so simple that a framework is 
unnecessary, but that doesn't mean that there should be no frameworks.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 02 Mar 2010 17:54:27 +0900

On 2010/03/01 10:18, Ian Hickson wrote:

> "Trivial demos" as you put it, or small-scale applications, as I would put
> it, are the main target audience I'm interested in. There are as many
> more applications in the long tail than in the head.
>
> I'm perfectly happy for this working group to work on a specification that
> targets a different target audience; I'm not trying to force a particular
> target audience on the working group. Personally, I'm interested in
> working on something that targets the long tail. If this is not something
> this working group is interested in, that's fine; I've no interest in
> blocking other work.

Not every application in the long tail is a 'trivial' or 'small-scale' 
(in terms of complexity) application. Indeed many large-scale (in terms 
of users) applications are in some ways simpler because scalability 
issues restrict their complexity (at least for some axes of complexity).

Also, some people write small-scale apps and know that they'll never 
have more  than a few users. Others start with something small-scale but 
really wouldn't mind to become the next Twitter or FaceBook or Google or 
what (and even if they don't get THAT far, they may soon be less 
'small-scale' than they imagined in the first place. I'm sure these 
people would prefer something that at least didn't come with a label of 
"caution, not designed to scale". (We can't claim something scales until 
it's actually deployed and does scale.)

I don't think this WG should target "small-scale" or "large-scale" 
audiences specifically. Technology is successful if it works on a large 
range of scales. That's why it's good to have people with all kinds of 
interests in this WG.

Regards,    Martin.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 02 Mar 2010 10:00:39 +0100

Ian,

the features needed by non trivial web applications
are going to have to be implemented somewhere: either
in the base protocol, in a framework or in the
application.

To advocate an ultra simple protocol and no frameworks
is to advocate that all features must be implemented
in the application.   If you want a no frameworks,
then surely you should be advocating a rich feature
set for the base protocol?

Or are you saying that the features commonly used by web
applications (eg threading, dispatch, authentication,
authorization, encoding, internationalization, logging,
content type handling, error handling, etc.) are
just not needed?

As I've said before, I think your ideas on web
application architecture are not exactly
main stream and I fear that you are attempting to use
the websocket protocol to drive an an agenda
for change.

Protocols and standards should be following the
existent use-cases and web application architectures.
They should not be developed in anticipation of
speculative brave new worlds of web architecture.

If you have some architectural ideas that you wish
to promote, then I suggest trying them out on some
real world applications somewhat more challenging
than naughts and crosses for 2 users.    If the
ideas have merit, then the approach will take
off and standards and protocols will be developed
to follow.

regards

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 02 Mar 2010 18:19:10 +0900

> Was this a problem in practice? I honestly don't recall.

As far as you can see from 
http://www.w3.org/DesignIssues/CompatibleProof, there wasn't a problem. 
But seen from 0.9, that was by accident (not every detail written down) 
and due to how the servers of the time (of which there were very few) 
were implemented, not by design.

Regards,   Martin.

---

From: "Alexander Philippou" <[email-masked]>
Date: Tue, 2 Mar 2010 12:30:32 +0200

> From: Ian Hickson [mailto:[email-masked]]

Example. Server supports XML, Fast Infoset and JSON as message encodings; it also supports GZIP, DEFLATE and LZF compression. Client connects and specifies in the header that it accepts "application/xml" and "application/fastinfoset" content types, and "gzip" content encoding. Server responds that, for this particular channel, "application/fastinfoset" will be the content type and "gzip" the content encoding for all messages exchanged by both sides.

So content negotiation enables services to be used in a manner that is most efficient for a particular situation. It enables the performance of Web services to be improved while retaining cross-platform interop and support for clients of different capabilities under a single service endpoint.

Does this answer your question or were you asking for something else?

Alexander

---

From: Ian Hickson <[email-masked]>
Date: Tue, 2 Mar 2010 10:50:51 +0000 (UTC)

On Tue, 2 Mar 2010, Alexander Philippou wrote:
> Example. Server supports XML, Fast Infoset and JSON as message 
> encodings; it also supports GZIP, DEFLATE and LZF compression. Client 
> connects and specifies in the header that it accepts "application/xml" 
> and "application/fastinfoset" content types, and "gzip" content 
> encoding. Server responds that, for this particular channel, 
> "application/fastinfoset" will be the content type and "gzip" the 
> content encoding for all messages exchanged by both sides.

Why would we specify more than one compression algorithm?

The message encodings are an application-layer issue (implemented in the 
JavaScript on the client), so that seems like something you'd implement in 
the subprotocol, not at the WebSocket layer.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 02 Mar 2010 12:01:25 +0100

>     http://dev.w3.org/html5/eventsource/

I had forgotten about this one. It would probably be good if the HTTP 
aspects of this spec got more review; I already sent a comment tp 
public-webapps that the new "Last-Event-ID" header appears to duplicate 
functionality you can already get from "If-None-Match".

Best regards, Julian

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 02 Mar 2010 12:49:45 +0100

> Why would we specify more than one compression algorithm?

Because preferred compression algorithms change over time.

gzip was not initially the preferred compression algorithm for HTTP
and may not remain so as content types and encodings used change
over time.

> the subprotocol, not at the WebSocket layer.

Actually, for this type of per connection negotiation, so long as
arbitrary headers are allowed in the upgrade request an 101
response (which they are), then I think client and server are
already able to use existing content negotiation (or not) as
they see fit.

Where I think we do need to consider content-type, is if
we wish to send polymorphic content.  eg, a stream of images
of various formats.    I think that mostly should be handled
by sub protocol, but I do think some base support for meta
data would prevent every sub protocol reinventing that wheel.

cheers

---

From: "Alexander Philippou" <[email-masked]>
Date: Tue, 2 Mar 2010 14:50:59 +0200

> Why would we specify more than one compression algorithm?

They have different performance characteristics. For example:
- LZF: medium compactness, very low processing overhead (also very small code)
- GZIP/DEFLATE: good compactness, medium processing overhead
- LZMA: high compactness, significant processing overhead (asymmetric: more on encoding, less on decoding)
- PPMs: high compactness, significant processing overhead (symmetric: same on encoding/decoding)

> the subprotocol, not at the WebSocket layer.

Absolutely agree that the implementation of compression or message encodings should be left to the application layer. Permitting the optional exchange of Accept, Accept-Encoding, Content-Type and Content-Encoding headers during WebSocket's initial HTTP handshake would be sufficient; the rest will be easily implementable by those of us interested in negotiating the content.

Alexander

---

From: <[email-masked]>
Date: Tue, 2 Mar 2010 14:21:18 +0100

Hi Ian,

Ian Hickson wrote:
>...is designed to be implementable in such a way that handsets 
>can offload the keepalive responsibility to the cell network 
>infrastructure, to avoid this problem. I wouldn't recommend 
>using WebSockets for server-push updates; when the client 
>isn't sending data, it's best to shut down the WebSocket 
>connection altogether.
>

This is certainly possible. Mobile operators do use SMS wake-up for some of their own services, such as Multimedia Messaging (MMS). But I foresee severe challenges with using it for Internet/Web applications. SMS is a service offered by mobile operators, and often they charge for it per message and the price varies per operator and region. So, this brings up the question of business relationships etc., which can limit the service uptake quite much. 

I'm definitely hoping that WebSocket will provide a reasonable channel for "server push", at least for all cases where HTTP long polling and/or streaming are used at the moment. I'm not holding my breath for getting SMS or any cellular network specific transport widely available for those use cases.

I understand that if there is a middlebox (proxy, NAT, whatever) that simply requires very frequent keep-alive, there's not much we can do in that case. But I also expect that the operators' awareness in these matters will grow, and many (not all) of them will configure their networks well, and in those situations WebSocket should be able to work well.

Markus

---

From: Ian Hickson <[email-masked]>
Date: Tue, 2 Mar 2010 20:37:12 +0000 (UTC)

> - PPMs: high compactness, significant processing overhead (symmetric: same on encoding/decoding)

How much of a difference are we talking about? A factor of 2? 10?

If it's less than an order of magnitude, the benefits gained would be 
outweighed by the damage of having more than one choice.

> > The message encodings are an application-layer issue (implemented in 
> > the JavaScript on the client), so that seems like something you'd 
> > implement in the subprotocol, not at the WebSocket layer.
> 
> Absolutely agree that the implementation of compression or message 
> encodings should be left to the application layer. Permitting the 
> optional exchange of Accept, Accept-Encoding, Content-Type and 
> Content-Encoding headers during WebSocket's initial HTTP handshake would 
> be sufficient; the rest will be easily implementable by those of us 
> interested in negotiating the content.

Why can't you do it in the first frame?

Mixing the higher-level protocol negotiation with the security handshake 
seems like a bad idea. In particular, part of the security of the 
handshake relies on the author having very little control over the ability 
to inject content into the handshake.

---

From: Pieter Hintjens <[email-masked]>
Date: Tue, 2 Mar 2010 22:38:26 +0100

> outweighed by the damage of having more than one choice.

Choice = damage?  I've rarely heard such a... singular analysis.

I thought choice meant, for example, that if an algorithm had flaws,
it could be replaced.  Performance is only one of many aspects.  Do
you recall something called GIF?

Not to mention the different qualities of service Alexander explained,
which already should make it clear why choice is valuable.

Even in your strange parallel universe where one size fits all, what
do you actually do if, ten years later, someone finds an algorithm
that is indeed 10x faster?  Do you say, "no, it should be 20x"?  Or
did you get a message from the future telling you what the compression
algorithm of 2020, or 2060 is going to be?

-Pieter

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 3 Mar 2010 06:00:51 +0800

This discussion is as good a recommendation for WS intermediaries as I've seen.

If a server requires keep alives and the device doesn't want to waste power providing them, a mismatch exists.

A device could identify a WS intermediary that uses a keep-alive mechanism that is compatible with the power management constraints on the device.  Between the device and intermediary, explicit keep-alives could be suppressed.  However, on the outgoing leg from the intermediary, normal keep alives could be maintained.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, 3 March 2010 12:21 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [hybi] Keepalive scenarios and client-side overhead (was
> Re: Various comments on recent threads)
> 
> Hi Ian,
> 
> Ian Hickson wrote:
> >
> This is certainly possible. Mobile operators do use SMS wake-up for
> some of their own services, such as Multimedia Messaging (MMS). But I
> foresee severe challenges with using it for Internet/Web applications.
> SMS is a service offered by mobile operators, and often they charge for
> it per message and the price varies per operator and region. So, this
> brings up the question of business relationships etc., which can limit
> the service uptake quite much.
> 
> I'm definitely hoping that WebSocket will provide a reasonable channel
> for "server push", at least for all cases where HTTP long polling
> and/or streaming are used at the moment. I'm not holding my breath for
> getting SMS or any cellular network specific transport widely available
> for those use cases.
> 
> I understand that if there is a middlebox (proxy, NAT, whatever) that
> simply requires very frequent keep-alive, there's not much we can do in
> that case. But I also expect that the operators' awareness in these
> matters will grow, and many (not all) of them will configure their
> networks well, and in those situations WebSocket should be able to work
> well.
> 
> Markus

---

From: Mridul Muralidharan <[email-masked]>
Date: Wed, 3 Mar 2010 15:22:06 +0530 (IST)

Just to understand better, here we are talking only of the first hop intermediary right ?
Or is it a general hop by hop keep alive being referred to (with first hop being a special case in this case which does not require keep alive ?)

Not sure how this works if the channel gets secured with tls/etc.

Regards,
Mridul

----- Original Message ----
> From: "Thomson, Martin" <[email-masked]>
> To: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Wed, 3 March, 2010 3:30:51 AM
> Subject: Re: [hybi] Keepalive scenarios and client-side overhead (was Re: Various comments on recent threads)
> 
> A device could identify a WS intermediary that uses a keep-alive mechanism that 
> is compatible with the power management constraints on the device.  Between the 
> device and intermediary, explicit keep-alives could be suppressed.  However, on 
> the outgoing leg from the intermediary, normal keep alives could be maintained.
> 
> --Martin
>

---

From: "Alexander Philippou" <[email-masked]>
Date: Wed, 3 Mar 2010 13:19:14 +0200

> How much of a difference are we talking about? A factor of 2? 10?

Different types/sizes of payloads can result in widely different compression ratios. Processing performance can also be significantly affected by the payload. And compressors don't necessarily follow the same patterns in their differences between different payloads. Compression performance is a per-use-case thing that, unfortunately, cannot be determined using a "factor of" approach.

> If it's less than an order of magnitude, the benefits gained would be outweighed by the damage of having more than one choice.

Sometimes the highest possible compression ratio is needed, others it's the consumption of processing power that matters most. For example, a low cpu/ram/battery device that only exchanges small messages at a local level will benefit more by the extremely low processing overhead of LZF, while the transmission of GBs of XML data by a remote but well powered observation station via satellite will benefit more by LZMA reducing message size by a few extra 100s of MB. If WebSocket is to facilitate the efficient use of computational/network resources then we need the ability to select the most appropriate compressor depending on the circumstances.

> Why can't you do it in the first frame?

Well, of course and it can be done. But this means that WebSocket will need an extra roundtrip to provide the same functionality as HTTP. And also content negotiation will end up being a proprietary solution, whereas in HTTP it is part of the standard.

> Mixing the higher-level protocol negotiation with the security handshake seems like a bad idea. In particular, part of the security of the handshake relies on the author having very little control over the ability to inject content into the handshake.

Isn't "Other fields" in 5.2 designed to include arbitrary data that WebSocket cannot understand and is actually to be processed by a higher level?

Alexander

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 03 Mar 2010 07:35:32 -0700

On 3/3/10 2:52 AM, "Mridul Muralidharan" <[email-masked]> wrote:

> Or is it a general hop by hop keep alive being referred to (with first hop
> being a special case in this case which does not require keep alive ?)
> 

It probably doesn't work hop-by-hop if we're doing end-to-end encryption.
That's a good argument for WS Intermediary Optimization being more complex
than the base protocol needs, to start with.

-- 
Joe Hildebrand
(as individual contributor)

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 3 Mar 2010 18:53:15 +0000

>    EventSource behaves identically at the protocol level (other than the

Last I read, XMLHttpRequest doesn't support streaming GET across all
major browsers.  You're not supposed to look at the xhr.responseText
until the object reaches the DONE state, which means the response is
ended.

Do you mean "long-polling GET" instead, where each batch of messages
from the server immediately ends the response and the browser
initiates another request?

Many months ago it was written on the hybi-list that long-polling GET
is reliable sometimes when streaming GET is not, although I never saw
a clear answer about when it's not reliable until Greg's recent
message about indefinite buffering in a proxy.  Earlier answers
suggested that proxies were fine and it was the browsers not always
delivering streamed data on time.

I still don't know of a good way to test if streaming GET is working
reliably.

>    uncacheable streaming response indefinitely?

I did notice some streaming implementations include things like "send
512 spaces after the response" to help buffering along.  It seems very
dubious to have an arbitrary number like that.

This relates to WebSocket: It's been stated that an intermediary is
not required to forward any part of a WebSocket message until the
whole message is received by the intermediary, and then it must
forward it.

That means if you attempt to set up a continuous byte stream by
issuing a very large binary message frame header, it can be buffered
indefinitely.

And if you do it by prefixing every chunk you send with a small binary
message frame header, that limits the efficiency in various ways.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 3 Mar 2010 19:01:06 +0000

> XMPP, IMAP, etc all benefit from long-lived, dormant connections.

Depends where you are.  On my phone, 30 seconds is needed for SSH
otherwise the mobile network blocks the connection on port 22.

Don't forget you have to send a keepalive more often than the NAT
timeout, because packets may still be arbitrarily delayed.

Especially on mobile networks: I see latency spiking from time to time
at 20 seconds, due to temporary signal dropouts and perhaps other
factors.  You have to reduce your keepalive time by that much.

> network behaviour takes over.

There are still networks which arbitrarily halt TCP connections from
time to time even if you are sending keepalives.

Home routers have a particular reputation for doing it when the number
of active TCPs hits a maximum value.

Don't forget that now that ADSL/cable internet is rolled out widely, a
lot of people are not going to upgrade their equipment for many years,
until they decide 20Mbps isn't fast enough.  My guess is current ADSL
NAT routers will still be in use in 10 years time, in enough
households to matter.

> typically, rather than per-application.

I agree fully.  I also agree with Greg's ideas on negotiating it
(although not necessarily the details), so that upgrades to one part
of the network can improve performance with things they connect to.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 3 Mar 2010 19:11:19 +0000

> XMPP, IMAP, etc all benefit from long-lived, dormant connections.

I agree, it's improving.  But redo the calculations with 2 minute
keepalives, and it's still quite a lot of traffic, like a lots of
little streams converging to make a river.

> network behaviour takes over.

I don't think keepalives can go away entirely.  At some level, there
is always a keepalive occurring, even if it's your mobile phone
pinging the base station, or your ethernet port continuously
transmitting an idle but alive signal.

For theoretical efficiency, it's a good idea, when possible and
dependable, to ask the lower layer to tell the higher layer when a
connection has gone away, rather then the higher layer continuously
sending keepalives to the other end's higher layer.  Unfortunately
that is very difficult to negotiate in practice: lower layers tend to
handle a single hop, and end-to-end keepalive is needed.  Besides,
it's rarely a good idea to trust lower layers to tell the truth
entirely because they aren't entirely dependable; just use them as hints.

Ian's "simple" Tic-Tac-Toe WebSocket example is broken due to missing
keepalives, in the following way:

If a client crashes, or goes offline, or has a temporary outage, then
the server will keep that client connection open _forever_ (i.e. until
the server reboots), thus repeating a problem with early 90s HTTP
servers needing to be rebooted every so often due to stuck connections.

> typically, rather than per-application.

Those are exactly the same reasons I've been advocating opportunistic
connection sharing (i.e. multiplexing) in the core.  It's a bit
complex, but framework implementors know *much* better than
application designers how to do it reliably and what parameters to
use.  Same reason we provide TCP in the OS and not per-application,
really.  It's ironic that HTTP is more efficient than WebSocket in
this respect.

-- Jamie

---

From: Ian Hickson <[email-masked]>
Date: Wed, 3 Mar 2010 19:12:47 +0000 (UTC)

On Wed, 3 Mar 2010, Alexander Philippou wrote:
> 
> Sometimes the highest possible compression ratio is needed, others it's 
> the consumption of processing power that matters most.

Seems to me that just using an algorithm that provides middle-of-the-road 
compression vs CPU usage is a good tradeoff for keeping the protocol 
trivial, even when we add compression.

> Well, of course and it can be done. But this means that WebSocket will 
> need an extra roundtrip to provide the same functionality as HTTP.

That seems like a small price to pay to keep the basic protocol trivial.

> And also content negotiation will end up being a proprietary solution, 
> whereas in HTTP it is part of the standard.

The whole subprotocol will be "a proprietary solution". That's the whole 
point of this protocol. It's just like how the format of a hanging GET's 
payload when using HTTP is "proprietary".

> > Mixing the higher-level protocol negotiation with the security 
> > handshake seems like a bad idea. In particular, part of the security 
> > of the handshake relies on the author having very little control over 
> > the ability to inject content into the handshake.
> 
> Isn't "Other fields" in 5.2 designed to include arbitrary data that 
> WebSocket cannot understand and is actually to be processed by a higher 
> level?

No. It's intended for future expansion of the base protocol, e.g. for when 
we add compression.

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 3 Mar 2010 19:14:00 +0000

> of active TCPs hits a maximum value.

And I've seen a big national retail network with 100Mbit links across
the UK that seem to reboot their big router once a day.  Losing all
active TCP connections through it (thousands), because they're all
NAT'd.  That stuff may fade away and change statistically, but I don't
see the need to handle it going away for many years.

- Jamie

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 04 Mar 2010 11:36:14 +0900

Hello Tim,

On 2010/03/01 4:18, Tim Bray wrote:
> I was thinking that I should put together a standalone client&  server in
> Ruby trying to use as much of Net::HTTP and Rack respectively as possible,
> to explore how much re-use is possible.
> Two questions:

Not that I knew.

> - Is this so far outside the design space as to be silly?

No, I think it's a very good idea.

Regards,   Martin.