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 at 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 at ietf.org > https://www.ietf.org/mailman/listinfo/hybi >
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.