Re: [hybi] Call for interest: multiplexing dedicated for WebSocket

Zhong Yu <zhong.j.yu@gmail.com> Wed, 22 May 2013 17:13 UTC

Return-Path: <zhong.j.yu@gmail.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 677FC21F96EF for <hybi@ietfa.amsl.com>; Wed, 22 May 2013 10:13:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 N9UFNKDRNxcq for <hybi@ietfa.amsl.com>; Wed, 22 May 2013 10:13:43 -0700 (PDT)
Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8B15121F8E8E for <hybi@ietf.org>; Wed, 22 May 2013 10:13:39 -0700 (PDT)
Received: by mail-oa0-f49.google.com with SMTP id k14so3071832oag.36 for <hybi@ietf.org>; Wed, 22 May 2013 10:13:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w/yR3er5NX44sNyPnF3idfoMK9VYkfTXcp7daO8lmZ0=; b=lHfqtLIJnp60EOZVz5sL/Ldg4iuOWlLhnMPGZOCp5CGvUchMgjTTHh/l68T9ZR53cL 8SFnGO8r6ik8N8wIaU26V5rYsxHMJ8C24A66bYJXZu5OqlbPGHRsyGd4rjamiGcw0gIl Mq5cRc03mgSG/4zhKn5nYYsCeyBelSYwzcDk4rozaoF6+AxDTiHjpgMnJ0nmKGTL6nGM sCpcVo5bFdZcoyeZJYptu1GNx0bTPNm/84MM/Z+ub7Dh6MCQeXBlwvsq4CLJ2Rp/qyz8 Sw7YxtQ77Fj1uEJBofZbmA7+HBIFrRp3GEMna5wDvirNeUm8RQuYw1mOkbjsi8MDWat/ NkpQ==
MIME-Version: 1.0
X-Received: by 10.182.138.4 with SMTP id qm4mr5652267obb.101.1369242819179; Wed, 22 May 2013 10:13:39 -0700 (PDT)
Received: by 10.76.98.227 with HTTP; Wed, 22 May 2013 10:13:39 -0700 (PDT)
In-Reply-To: <CAM5k6X9WmO80hiQZ6_GqK66PAd3of=2ZRi9=VrWj52apA1+=5g@mail.gmail.com>
References: <CAH9hSJZxr+aG7GZa4f-dUOTGj4bnJ+3XxivUX4jei5CMyqN4LQ@mail.gmail.com> <CAH9hSJZUG1f+3Uk=t2=A5i4O9=wPvAisspM=pgmGEH9emTL9-Q@mail.gmail.com> <CAH9hSJZai_UuxW4O6mZcEJT2DJoURtLo16XNci1qkYVWv4HVdg@mail.gmail.com> <007501ce56f0$67f74080$37e5c180$@noemax.com> <519CD6A1.7080708@ericsson.com> <519CE075.4000106@tavendo.de> <CAM5k6X9WmO80hiQZ6_GqK66PAd3of=2ZRi9=VrWj52apA1+=5g@mail.gmail.com>
Date: Wed, 22 May 2013 12:13:39 -0500
Message-ID: <CACuKZqEXghX9ONECBGTEB1cD5Pt5cakKih9unjSZAmFnHZ1f2A@mail.gmail.com>
From: Zhong Yu <zhong.j.yu@gmail.com>
To: "John A. Tamplin" <jat@jaet.org>
Content-Type: multipart/alternative; boundary=e89a8ff1cd0ed93bd404dd51af4f
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Wed, 22 May 2013 17:13:48 -0000

On Wed, May 22, 2013 at 11:26 AM, John A. Tamplin <jat@jaet.org> wrote:

> On Wed, May 22, 2013 at 11:12 AM, Tobias Oberstein <
> tobias.oberstein@tavendo.de> wrote:
>
>> +1 for the simplest possible mux that does the core job.
>>
>> However, I currently think that having a per-logical channel flow control
>> is required to make it useful (cannot be dropped for the sake of
>> simplification). I might be wrong.
>>
>
> I agree -- without flow control, there is very little benefit, and almost
> nothing that an app couldn't easily do themselves by just adding a simple
> framing layer inside WS messages (perhaps just the first byte is a logical
> channel number).
>
>
In traditional socket programming model, the application chooses the time
and the speed to perform read(). If the application is not reading fast
enough, the receive buffer is full and more incoming data are not welcome.

Contrary to that, most WebSocket API are event based - all incoming message
data are buffered without any blocking, then the complete message is sent
to the application callback. In this model, per channel flow control
doesn't seems to exist.

If per channel flow control is removed from the spec, what use cases would
suffer?

--
And I have a stupid question - what's the motivation to do mux on
WebSocket? To save local port numbers? To avoid slow start? If we drop mux
all together, what use cases would suffer?

Zhong Yu