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
>