Re: [hybi] Is there a traffic jam?

Ian Hickson <ian@hixie.ch> Tue, 14 April 2009 01:16 UTC

Return-Path: <ian@hixie.ch>
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 DCDAC3A689A for <hybi@core3.amsl.com>; Mon, 13 Apr 2009 18:16:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level:
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_00=-2.599]
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 Qx51x+b-ttBB for <hybi@core3.amsl.com>; Mon, 13 Apr 2009 18:16:33 -0700 (PDT)
Received: from looneymail-a3.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id F35E43A6765 for <hybi@ietf.org>; Mon, 13 Apr 2009 18:16:32 -0700 (PDT)
Received: from hixie.dreamhostps.com (hixie.dreamhost.com [208.113.210.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a3.g.dreamhost.com (Postfix) with ESMTP id 7201427B77; Mon, 13 Apr 2009 18:17:44 -0700 (PDT)
Date: Tue, 14 Apr 2009 01:17:44 +0000
From: Ian Hickson <ian@hixie.ch>
To: Greg Wilkins <gregw@webtide.com>
In-Reply-To: <49E3E229.2060907@webtide.com>
Message-ID: <Pine.LNX.4.62.0904140110040.10339@hixie.dreamhostps.com>
References: <03BCE29D-7AA5-4128-9F61-446E0229479A@lindenlab.com> <E51D5B15BFDEFD448F90BDD17D41CFF105A0C46E@AHQEX1.andrew.com> <Pine.LNX.4.62.0904132352430.10339@hixie.dreamhostps.com> <E51D5B15BFDEFD448F90BDD17D41CFF105A0C476@AHQEX1.andrew.com> <Pine.LNX.4.62.0904140002360.10339@hixie.dreamhostps.com> <1cb725390904131712k292a4860pbd078bb251d3855b@mail.gmail.com> <Pine.LNX.4.62.0904140031040.10339@hixie.dreamhostps.com> <1cb725390904131752u5842c039wb3d75602c479fa45@mail.gmail.com> <Pine.LNX.4.62.0904140053050.10339@hixie.dreamhostps.com> <49E3E229.2060907@webtide.com>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: hybi@ietf.org
Subject: Re: [hybi] Is there a traffic jam?
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: Tue, 14 Apr 2009 01:16:34 -0000

On Tue, 14 Apr 2009, Greg Wilkins wrote:
>
> Having a simple approachable API for use by 12 year olds and 70 years 
> old is great!  But there is not need for that simplicity to be reflected 
> in the protocol, or for the protocol to not support other more complex 
> APIs (or indeed multiplexing of many instances of the simple API).

The 12 year olds and 70 year olds in the scenarios I described are the 
people who would be writing the server-side components also. So yes, there 
is a _critical_ need for the simplicitly to be reflected in the protocol.

A simple protocol doesn't preclude more complex APIs, or multiplexing. 

For example, instead of having frames like this:

 +-FRAME-------------+-DATA----------------+
 | +-----+---------+ | +-----------------+ |
 | | ... | Channel | | | Message         | |
 | +-----+---------+ | +-----------------+ |
 +-------------------+---------------------+

...where the Channel part of multiplexing is a core part of the protocol 
that _everyone_ has to deal with, we can just as easily have:

 +-FRAME---+-DATA--------------------------+
 | +-----+ | +---------+-----------------+ |
 | | ... | | | Channel | Message         | |
 | +-----+ | +---------+-----------------+ |
 +---------+-------------------------------+

...where the Channel part is part of the application-level protocol. 
Instead of putting multiplexing into the core API and wire protocol, 
people can implement it using custom APIs and custom formats over the 
basic wire protocol.

This is just like the way that TCP has no support for individual blocks 
over a connection -- it's a streaming protocol. But we can layer blocks on 
top of TCP. That's not a failing of TCP.

(In these diagrams the "..." bit represents whatever other per-frame 
metadata we might have; in WebSockets right now this is just a frame type 
byte and a length for binary frames.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'