Re: [hybi] web socket protocol in "last call"?
Mike Dierken <mike@dierken.com> Sun, 01 November 2009 03:29 UTC
Return-Path: <mike@dierken.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7F33A6781 for <hybi@core3.amsl.com>; Sat, 31 Oct 2009 20:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.777
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gAkZI3DkdwZ for <hybi@core3.amsl.com>; Sat, 31 Oct 2009 20:29:19 -0700 (PDT)
Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 7A6673A6359 for <hybi@ietf.org>; Sat, 31 Oct 2009 20:29:19 -0700 (PDT)
Received: by pxi1 with SMTP id 1so2863722pxi.32 for <hybi@ietf.org>; Sat, 31 Oct 2009 20:29:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.143.27.41 with SMTP id e41mr316058wfj.218.1257046175437; Sat, 31 Oct 2009 20:29:35 -0700 (PDT)
In-Reply-To: <Pine.LNX.4.62.0910310127390.25616@hixie.dreamhostps.com>
References: <4AE7F0AE.1000102@gmx.de> <Pine.LNX.4.62.0910280740540.25608@hixie.dreamhostps.com> <4AE7FFC4.8050405@gmx.de> <4AE806AA.60901@ericsson.com> <Pine.LNX.4.62.0910280938560.25608@hixie.dreamhostps.com> <4AE86513.4060600@ericsson.com> <3a880e2c0910281301j5d1e4cdclfe2391b28eadda0e@mail.gmail.com> <4AE8CA69.2040105@webtide.com> <44abafb90910281604o2a73b490l6b1ae5ca1fba37ba@mail.gmail.com> <Pine.LNX.4.62.0910310127390.25616@hixie.dreamhostps.com>
Date: Sat, 31 Oct 2009 20:29:35 -0700
Message-ID: <3f5bf96b0910312029l3a0f755ax39349988fefb53b@mail.gmail.com>
From: Mike Dierken <mike@dierken.com>
To: Ian Hickson <ian@hixie.ch>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] web socket protocol in "last call"?
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=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 <ian@hixie.ch> 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 > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi >
- Re: [hybi] web socket protocol in "last call"? Julian Reschke
- [hybi] web socket protocol in "last call"? Julian Reschke
- Re: [hybi] web socket protocol in "last call"? Ian Hickson
- Re: [hybi] web socket protocol in "last call"? Salvatore Loreto
- Re: [hybi] web socket protocol in "last call"? Ian Hickson
- Re: [hybi] web socket protocol in "last call"? Julian Reschke
- Re: [hybi] web socket protocol in "last call"? Salvatore Loreto
- Re: [hybi] web socket protocol in "last call"? Infinity Linden (Meadhbh Hamrick)
- Re: [hybi] web socket protocol in "last call"? Maciej Stachowiak
- Re: [hybi] web socket protocol in "last call"? Infinity Linden (Meadhbh Hamrick)
- Re: [hybi] web socket protocol in "last call"? Greg Wilkins
- Re: [hybi] web socket protocol in "last call"? Martin Tyler
- Re: [hybi] web socket protocol in "last call"? Julian Reschke
- Re: [hybi] web socket protocol in "last call"? Ian Hickson
- Re: [hybi] web socket protocol in "last call"? Mike Dierken
- Re: [hybi] web socket protocol in "last call"? Ian Hickson
- Re: [hybi] web socket protocol in "last call"? Jamie Lokier
- Re: [hybi] web socket protocol in "last call"? Lisa Dusseault