Re: [hybi] web socket protocol in "last call"?

Mike Dierken <> Sun, 01 November 2009 03:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD7F33A6781 for <>; Sat, 31 Oct 2009 20:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.777
X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_44=0.6, J_CHICKENPOX_84=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9gAkZI3DkdwZ for <>; Sat, 31 Oct 2009 20:29:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7A6673A6359 for <>; Sat, 31 Oct 2009 20:29:19 -0700 (PDT)
Received: by pxi1 with SMTP id 1so2863722pxi.32 for <>; Sat, 31 Oct 2009 20:29:35 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id e41mr316058wfj.218.1257046175437; Sat, 31 Oct 2009 20:29:35 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Sat, 31 Oct 2009 20:29:35 -0700
Message-ID: <>
From: Mike Dierken <>
To: Ian Hickson <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [hybi] web socket protocol in "last call"?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 01 Nov 2009 03:29:20 -0000

It's good to see progress on messaging technologies for browsers and
other user agents.

I had one small question about "[..] the latency involved in having to
establish new TCP
connections for each HTTP message is non-existent in WebSocket". I
know that you know that persistent HTTP 1.1 connections reduce the
number of times an open/close of a connection would occur, so I was
curious what's actually happening that connections are created for
each request. (Not that I think the answer will or should change
anything to do with WebSockets, just a curiousity sort of thing).

On Fri, Oct 30, 2009 at 8:35 PM, Ian Hickson <> wrote:
> On Wed, 28 Oct 2009, Salvatore Loreto wrote:
>> Ian Hickson wrote:
>> >
>> > There's a couple of e-mails from earlier today that I haven't yet
>> > considered, but other than that, I've read and considered all the
>> > e-mails to this list, and provided detailed reasons for rejecting any
>> > proposals I've not adopted. If I missed one, please let me know.
>> actually in the IETF process one of the main reason to accept or reject
>> a proposal/issue/"request to change something" is based on *"rough
>> consensus"* reached among people involved in the mailing list
>> discussion, especially when the reason for accepting or rejecting are
>> based more on philosophical then technical issues.
> I must admit to being more interested in technical soundness than
> consensus. However, if we are to base things on consensus, then we need an
> objective definition of consensus, so that it can be determined when we do
> or do not have consensus. Is there such a definition?
>> The decision to adopt or not a proposal should come from the consensus
>> and not from the decision of a single person. I am sorry to notice,
>> following the ml discussion, that a lot of the proposals have been
>> discarded for philosophical reasons even if the majority of the people
>> in the ml were in favour. I am not saying that you should adopt them
>> straight, but only that you should keep open the discussion on
>> controversial issues and seek a sort of consensus, among people involved
>> in the discussion, on how to solve them
> I thought that's what I was doing: responding to proposals with counter
> proposals, evaluating arguments on technical merit, and taking part in the
> continuing debates. Surely you are not suggesting that anybody has been
> preventing anyone from continuing the discussions?
> On Wed, 28 Oct 2009, Infinity Linden (Meadhbh Hamrick) wrote:
>> wow. WS is in last call? not being able to continue work on putting
>> something like RHTTP or BWTP over WS is a bit of a deal-breaker for me.
> Nobody is suggesting stopping work on anything, as far as I am aware.
>> i guess there's also no reason now to meet at apachecon next week about
>> WS. i mean, why bother meeting about something you can't change?
> "Last call" is not the end of the process. If you have feedback, please
> don't hesitate to send it.
>> WS is essentially unusable for me in it's current form. or rather, i
>> could use it, but why? my use case of establishing reverse
>> request-response semantic recognizable by intermediaries that supports
>> channel multiplexing is possible over WS, but then again, it's also
>> possible by extending HTTP, so why not just do that?
> Could you elaborate on your use case?
> WebSocket is a better substrate for bidirectional communication than HTTP
> in some specific ways: the latency involved in having to establish new TCP
> connections for each HTTP message is non-existent in WebSocket, the
> overhead of HTTP headers with each request (leading to 1000:1
> overhead:data ratios when sending simple messages like "the user pressed
> 'a'") is minimised in WebSocket (the kilobytes of headers overhead in HTTP
> is reduced to two bytes in WebSocket), and the difficulties on the
> server-side of associating outgoing connections with incoming connections
> is removed (there's only one TCP connection in WebSocket).
> What problems are you having that WebSocket _doesn't_ solve, or prevents
> you from solving?
> On Wed, 28 Oct 2009, Infinity Linden (Meadhbh Hamrick) wrote:
>> HyBi has a few people who are interested primarily in (bidirectional)
>> HTTP as a substrate for other application layer protocols. is there a
>> similar constituency in WHATWG? (probably should have asked this way
>> earlier.) in other words, while i think pushing HTML+JPEG over HTTP is
>> cool and about the only use case browser vendors are going to worry
>> about; my personal interest is in pushing xml, json, and random weird
>> BASE64 encoded binary blobs with metadata over the connection.
> As far as I can tell, the use case of sending occasional large blobs of
> data to the server from the client is already addressed by HTTP (via
> XMLHttpRequest on the client), so I don't think there's a need for Web
> browsers to implement new protocols to support it. However, I have no
> objection to the working group developing a technology to support this.
> On Thu, 29 Oct 2009, Greg Wilkins wrote:
>> I completely agree with this sentiment.  WS is usable, but provides no
>> significant benefit over HTTP other than a warm philosophical feeling
>> that you are not abusing HTTP, is a little more byte efficient and
>> marginally better latency.
> Reducing kilobytes of data to 2 bytes is more than "a little more byte
> efficient", and reducing latency from 150ms (TCP round trip to set up the
> connection plus a packet for the message) to 50ms (just the packet for the
> message) is far more than marginal. In fact, these two factors alone are
> enough to make WebSocket seriously interesting to Google.
>> But it is not going to scale for my use-cases because of the connection
>> bloat.
> It halves the number of connections relative to current solutions. I would
> hardly characterise one connection per user as bloat -- it's the same
> model used by IMAP, SSH, and IRC, to name but three protocols I'm using
> right now.
>> It's going to break all the load balancers I work with and the SSL
>> offloaders and most other network infrastructure.
> Could you elaborate on what requirements your load balancers and SSL
> offloaders have which, if addressed, would lead to WebSocket working with
> them to your satisfaction?
>> Failing consensus on the protocol, I would have really liked the
>> opportunity of having a service provider API in the browser - so I could
>> intercept standard ws API and transport it over something that would
>> work my use-cases, or inserting layers between app API and transport.
> I don't think that's impossible -- as with any browser feature, the first
> step is convincing browser vendors that they should implement such a
> feature. Generally I work the other way around -- I listen to browser
> vendors, then spec what they say they want to implement. But sometimes
> it's possible to convince browser vendors that they want to implement
> something. However, it doesn't matter what the Hybi group does -- browser
> vendors don't automatically implement something the IETF or W3C invent.
> They have to want to implement it.
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> _______________________________________________
> hybi mailing list