Re: [hybi] Multiplexing in WebSocket (Was: HyBi Design Space)
Wellington Fernando de Macedo <wfernandom2004@gmail.com> Sun, 18 October 2009 19:39 UTC
Return-Path: <wfernandom2004@gmail.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 DF2DF3A67B0 for <hybi@core3.amsl.com>; Sun, 18 Oct 2009 12:39:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.665
X-Spam-Level: ****
X-Spam-Status: No, score=4.665 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, SARE_RECV_SPAM_DOMN02=1.666, SARE_RMML_Stock4=1.54]
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 93x3nr7YG5TO for <hybi@core3.amsl.com>; Sun, 18 Oct 2009 12:39:52 -0700 (PDT)
Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by core3.amsl.com (Postfix) with ESMTP id 5B4673A67F2 for <hybi@ietf.org>; Sun, 18 Oct 2009 12:39:52 -0700 (PDT)
Received: by qyk29 with SMTP id 29so2737061qyk.32 for <hybi@ietf.org>; Sun, 18 Oct 2009 12:39:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id :disposition-notification-to:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZN2b75a/mMwVKrHIjPI3tOz/D8dDhnYln1QzKwK/W/U=; b=TJkS72oLvbo4S63PKDbbS5ETITj1cgCYhHSQsKUz3G+TZldOzMtp7BwAvf7a2ic6Dp NqA4gbeIOXMIP459M+4l8Rq3udIMUokKz8KB/3X7aSMzJ1qkFdS4348ChwI6oSzTFjah TLKjklVd5wdtBRLjRFNzfj0eDLx5H4u5H1Omw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; b=DYgkEizmiis6+z02L5hToC6aFnHB3eY1OmxXhTo1hePOJeIZqN2bqpSPt6rK0OqErV ffZwavDurC2PN7ktaeqGdTTYnD+KvIl32rSdoDlCdq6Fqy0waJITn0EoZZhlc5JoOx6y BJsWCgB7Dw+qJoUNpWwclmag5ugvcRz7TpL20=
Received: by 10.224.4.131 with SMTP id 3mr2219458qar.141.1255894793507; Sun, 18 Oct 2009 12:39:53 -0700 (PDT)
Received: from ?192.168.1.101? (201-92-95-217.dsl.telesp.net.br [201.92.95.217]) by mx.google.com with ESMTPS id 23sm2914503qyk.11.2009.10.18.12.39.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 18 Oct 2009 12:39:52 -0700 (PDT)
Message-ID: <4ADB6F0B.4000004@gmail.com>
Date: Sun, 18 Oct 2009 17:39:55 -0200
From: Wellington Fernando de Macedo <wfernandom2004@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Ian Hickson <ian@hixie.ch>, hybi@ietf.org
References: <4ACE50A2.5070404@ericsson.com> <3a880e2c0910081600v3607665dp193f6df499706810@mail.gmail.com> <4ACF4055.6080302@ericsson.com> <Pine.LNX.4.62.0910092116010.21884@hixie.dreamhostps.com> <4AD2E353.8070609@webtide.com> <4AD2F43D.6030202@ninebynine.org> <4AD39A64.4080405@webtide.com> <Pine.LNX.4.62.0910132335390.25383@hixie.dreamhostps.com> <4AD53DCA.6050304@webtide.com> <Pine.LNX.4.62.0910170203460.9145@hixie.dreamhostps.com> <4ADA7FD4.9010406@webtide.com>
In-Reply-To: <4ADA7FD4.9010406@webtide.com>
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [hybi] Multiplexing in WebSocket (Was: HyBi Design Space)
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, 18 Oct 2009 19:39:54 -0000
I would like to make a contribution to this discussion. I think the ws protocol is good as it is right now. But I think multiplexing is a valuable feature. I don't like the BWTP proposal because I think it is expensive. Considering the current protocol, I suggest we introduce "channel handshakes", using another frame type. Each WebSocket object instance would be associated with one channel. I don't intend to make another proposal, so I will illustrate what I'm thinking using an example and I hope it can be useful someway :)
1. Suppose there is already a established connection:
User agent
-------------
GET /ws/script1.php HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: http://www.myhost.com" rel="nofollow">www.myhost.com
Origin: file://
CR LF
Server
-------------
HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
websocket-origin: file://
websocket-location: ws://www.myhost.com/ws/script1.php
CR LF
2. A normal exchange of data.
User Agent
--------------
0x00 ping 0xff
Server
--------------
0x00 pong 0xff
3. In the meanwhile the user agent has to open ws://www.myhost.com/ws/script2.php. Then, using the same connection, the user agent could use the 0x01 frame type as a way to perform the "channel handshake". Also, the request must have a websocket-channel-id header (containing a two bytes number value) which would identity the channel.
User Agent
--------------
0x01 GET /ws/script2.php HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: http://www.myhost.com" rel="nofollow">www.myhost.com
Origin: file://
websocket-channel-id: 1
CR LF 0xff
Server
-------------
0x01 HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
websocket-origin: file://
websocket-location: ws://www.myhost.com/ws/script2.php
websocket-channel-id: 1
CR LF 0xff
4. Since that, both channels could exchange data using a third frame type (0x02), followed by the channel id. The initial channel could still use the 0x00 frame type, however. For instance, a exchange of data on the initial channel would be:
User Agent
--------------
0x00 ping 0xff
Server
--------------
0x00 pong 0xff
or
User Agent
--------------
0x02 0x00 0x00 ping 0xff
Server
--------------
0x02 0x00 0x00 pong 0xff
4. And a exchange of data on the new channel:
User Agent
--------------
0x02 0x00 0x01 ping 0xff
Server
--------------
0x02 0x00 0x01 pong 0xff
It is all.
Wellington.
Wellington Fernando de Macedo
Engenharia de Computação
Telefone: +55 (16) 8144.8607
Greg Wilkins escreveu:
Ian Hickson wrote:Then the author really should just combine the event sources into one (or use the EventSource featureBut there might not be 1 author! Mash-ups and portals and such things will combine the work of many authors unknowingly onto the same page. We want to encourage reuse of components and not require every webapp to be rewritten from scratch with a shared messaging infrastructure.Could you describe the scenario in which you imagine an application needing multiple two-way communication channels one after the other, each for short periods of time, each with a different server-side development team? I'm not really seeing the use case here.Consider the google home page. This can be customized with lots of widgets from third parties. Imagine the same sort of site, but fronting an organization with lots of real time data. A stock trading site for example. They may allow a user to populate their pages with widgets supplied by third parties that may perform all sorts of trading analysis, monitoring and trading. I widget may establish "connections" to: + receive live price information + monitor the state of orders placed + interact with others in a process to create a complex instrument, swap etc. These "connections" may be short or long lived (who knows how long an order might take to complete). For scalability of the service, you don't want every widget to be given it's own TCP/IP connection. Even if you can handle the load, it is an unfair allocation of server resources to give more to those with more widgets on their desktops These widgets should all multiplex onto the same TCP/IP connection per user. Of course the organization could provide a js framework that did that multiplexing - but widget developers would be highly unlikely to use it. If they use websocket directly, then the code they write can access the service both in the portal site and from other sites that don't have the framework. Plus if they don't use the framework, they get their own dedicated TCP/IP connection and they will get some latency/performance benefits of other widgets that are sharing a connection. Of course this creates an arms race as it only works if everbody else is sharing. Soon all widgets will be using their own dedicated connection, then each widget would start opening multiple dedicated connections (eg 1 per share), trying to get more and more resources allocated. Developers and resources are like 3 years olds and toys! There is no such thing as optional sharing!You are assuming monolithic servers like Apache, with multiple frameworks plugged into those servers. I'm imagining 100-line perl scripts. While we have such differing goals, ... In this world, there is no server to handle the multiplexing across multiple frameworks.I really do not think you should be using your influence over the websocket protocol to drive some agenda to revolutionize server side development. We cannot design a protocol that is only suitable for some imagined future scenario. Trying to enforce this future by making future protocols badly support monolithic servers strikes me as some Orwellian mind control exercise!If the channels are multiplexed, then we're assuming that the server-side is an "aggregating resource" as you put it. If it's possible to use an aggregating resource with a multiplexed connection, then why would it not be possible to do it with a Web Socket connection? I don't understand.Because in the real world, we have one set of developers writing servers and user-agents and another set of developers writing applications that run on them. The infrastructure developers impose all sorts of restrictions on the application developers: + sharing CPU and memory with other users/processes. + sharing connection and network infrastructure + enforcing origin policies, security sand boxes etc. etc. etc. In your brave new world, there are no infrastructure developers, only application developers. In this world, the application developers will throw off the infrastructure shackles imposed on them, because indeed a dedicated TCP/IP connections is better than a shared one. Cross domain development is so much easier without security models etc. Better let them run as root as well, because then they can open any port and up their priority to stop sharing CPU. There are really really good reasons why infrastructure is developed for application developers. Infrastructure is not only to enable applications, but it is to constrain them and to force them to share resources fairly and to respect security models. But there is absolutely no way that any responsible organisation is going to deploy a system where sockets opened by applications programmers are exposed directly to the internet and run with ad-hoc protocol implementations.Servers already have to deal with multiple connections per user, for HTTP. I do not see how WebSocket makes things worse.Multiple connections are allowed for HTTP as a necessary evil to get around the intrinsic latency of the request/response protocol that does not support message fragmentation or out of order responses. Even then HTTP is meant to restricted to 2 connections. Stupidly Recent user-agents have engaged in exactly the sort of arms race I have describe above... lets have 8 connections and we are faster than the other guys... doh! they have 8 too, ok lets have 16.... doh! 32! ... doh!If your OS' kernel is badly optimised such that multiple connections are expensive, then instead of changing the protocol, fix the kernel.it's not bad optimization. If you have 1 connection, you need 1 set of buffers and when it is full you give back pressure on that TCP connection. If you have 10 connections, you need 10 sets of buffers and you have to wait until you have received 10x the data from one user before you apply back pressure. The optimization you are looking for is to make that user share 1 connection instead of using 10! There is no other way to optimize away the buffer requirements!I assume it is a given that you would want a protocol to have the property that connecting with path A, then opening a channel for path B, should result in a connection with the same internal state as connecting with path B, then opening a channel for path A. Given the HTTP Upgrade mechanism whereby an HTTP server can have a WebSocket script assigned to each path, you can end up in a situation where connecting to A and connecting to B establish connections with different server-side scripts.How so. I'm advocating abstracting developers away from connections. Handler A will send/receive messages for path A Handler B will send/receive messages for path B Neither handler has any need to know if a shared connection was used or not.The entire purpose of Web Socket is to provide a TCP connection to JavaScript. That's the goal.Really? If it was, then why not just expose the real socket API? Surely the aim is to establish bidirectional communication with the server. Whose to say that TCP/IP will be the favoured transport for the entire life span of the applications using the websocket API? In any case, if the IETF is to endorse a new web protocol, I believe that their charter is to consider more than just the needs of javascript developers. regards _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi" rel="nofollow">https://www.ietf.org/mailman/listinfo/hybi
- [hybi] HyBi Design Space Salvatore Loreto
- Re: [hybi] HyBi Design Space Infinity Linden (Meadhbh Hamrick)
- Re: [hybi] HyBi Design Space Thomson, Martin
- Re: [hybi] HyBi Design Space Salvatore Loreto
- Re: [hybi] HyBi Design Space Salvatore Loreto
- [hybi] Multiplexing in WebSocket (Was: HyBi Desig… Ian Hickson
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Julian Reschke
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Infinity Linden (Meadhbh Hamrick)
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Greg Wilkins
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Graham Klyne
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Greg Wilkins
- Re: [hybi] HyBi Design Space Stefano Salsano
- Re: [hybi] HyBi Design Space Thomson, Martin
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Graham Klyne
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Ian Hickson
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Ian Hickson
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Greg Wilkins
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Ian Hickson
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Jamie Lokier
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Ian Hickson
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Greg Wilkins
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Greg Wilkins
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Julian Reschke
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Julian Reschke
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Michael(tm) Smith
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Julian Reschke
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Bjoern Hoehrmann
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Ian Hickson
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Julian Reschke
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Ian Hickson
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Julian Reschke
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… SM
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Ian Hickson
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Martin Tyler
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Ian Hickson
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Julian Reschke
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Greg Wilkins
- Re: [hybi] Multiplexing in WebSocket (Was: HyBi D… Wellington Fernando de Macedo
- [hybi] new drat design-space-bidirectional Salvatore Loreto
- Re: [hybi] Multiplexing in WebSocket Ian Hickson
- Re: [hybi] Multiplexing in WebSocket Greg Wilkins
- Re: [hybi] Multiplexing in WebSocket Ian Hickson
- Re: [hybi] Multiplexing in WebSocket Julian Reschke
- Re: [hybi] Multiplexing in WebSocket Ian Hickson
- Re: [hybi] Multiplexing in WebSocket Peter Saint-Andre
- Re: [hybi] Multiplexing in WebSocket Greg Wilkins
- Re: [hybi] Multiplexing in WebSocket Ian Hickson
- Re: [hybi] Multiplexing in WebSocket Greg Wilkins
- Re: [hybi] Multiplexing in WebSocket Jamie Lokier
- Re: [hybi] Multiplexing in WebSocket Greg Wilkins
- Re: [hybi] Multiplexing in WebSocket Greg Wilkins
- Re: [hybi] Multiplexing in WebSocket Ian Hickson
- Re: [hybi] Multiplexing in WebSocket Greg Wilkins
- Re: [hybi] Multiplexing in WebSocket Ian Hickson