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

[Mike Dierken <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>