[hybi] Multiplexing: even/odd client/server channel open

Scott Ferguson <ferg@caucho.com> Tue, 26 June 2012 22:41 UTC

Return-Path: <ferg@caucho.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182CC21F84FE for <hybi@ietfa.amsl.com>; Tue, 26 Jun 2012 15:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZV94CYmENCie for <hybi@ietfa.amsl.com>; Tue, 26 Jun 2012 15:41:30 -0700 (PDT)
Received: from nm12-vm0.access.bullet.mail.mud.yahoo.com (nm12-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.11]) by ietfa.amsl.com (Postfix) with SMTP id AC75F21F8504 for <hybi@ietf.org>; Tue, 26 Jun 2012 15:41:28 -0700 (PDT)
Received: from [66.94.237.200] by nm12.access.bullet.mail.mud.yahoo.com with NNFMP; 26 Jun 2012 22:41:28 -0000
Received: from [98.138.206.46] by tm11.access.bullet.mail.mud.yahoo.com with NNFMP; 26 Jun 2012 22:41:28 -0000
Received: from [127.0.0.1] by smtp109.biz.mail.ne1.yahoo.com with NNFMP; 26 Jun 2012 22:41:28 -0000
X-Yahoo-Newman-Id: 105826.84097.bm@smtp109.biz.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: cjdttdYVM1kNucq1MQIX.VlK_ZXv6DCSBBwp7nxQKe4XJhi B82AQruIzVCNmwPJXZDWSXTOHZrYMrPFwfX6DavrCFV2rrxmJcmTtSNv9D4Q 2.bud.5U0CQwu9dClmU9RrlGaaltMgWmvzTJJzrbqGF.0RtazrpKcG2koopc gWTQZ8biGNhWrbi1oaPCWVZ74H_8LXWoobpcAEG0KGW84L.jE_vZydjIgwCV fj4HAC.1Bamrmq0QNCqwnwsegpAfwNMXs.uBzE84DUtRmYI3LLDJiSCwIJHp .ViwddtXPppUFN16FBv9ep8ErXyfFikt1m_aMHjs2Xd1hI6fmEHlKxK3pITD K86e_LeqasP76fZogwu2AOxST_MjOKjwBRVnt7ABPgkK806WKpjxC06_._iI OHrGEWEvJhJKxG.xWqNij6IHBoBs-
X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C
Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp109.biz.mail.ne1.yahoo.com with SMTP; 26 Jun 2012 15:41:27 -0700 PDT
Message-ID: <4FEA3A97.5030301@caucho.com>
Date: Tue, 26 Jun 2012 15:41:27 -0700
From: Scott Ferguson <ferg@caucho.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "hybi@ietf.org" <hybi@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [hybi] Multiplexing: even/odd client/server channel open
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ferg@caucho.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 26 Jun 2012 22:41:31 -0000

In the current draft, only the client can open channels and it can open 
any channel id.

In http-ng (and spdy, I believe), half the channel ids (even) are 
reserved to the client and half the channel ids (odd) are reserved to 
the server.

This splitting of the channel space allows either end to open a new 
channel without collision. Since spdy is already experimenting with the 
use of server-initiated channels, it's not unreasonable to suppose that 
some websocket applications may want similar capabilities. (Presumably 
non-browser apps or spdy-over-websocket.)

Alternatively, the odd channels could be reserved for future expansion 
without adding server-initiated channels now, allowing a later version 
of mux to add server-initiated channels.

I didn't see a previous discussion on this topic, but I skimmed fairly 
quickly, so disregard if it's been discussed already.

I'd think reserving odd channel ids would be a straightforward 
improvement to avoid locking in the client-only limitation of the 
current draft, even if it was decided that server initiated channels 
should be avoided for the current spec.

-- Scott