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

Simone Bordet <> Wed, 22 May 2013 16:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B883211E80FF for <>; Wed, 22 May 2013 09:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y72N2ZWamfcA for <>; Wed, 22 May 2013 09:50:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4B19721F96F9 for <>; Wed, 22 May 2013 09:48:44 -0700 (PDT)
Received: by with SMTP id 10so1897505pdc.39 for <>; Wed, 22 May 2013 09:48:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=I77T8lcEMHDJjlnXn1BIXcWqAWchRv7xfZ2a6Sl4mns=; b=lpQtT50ES9T7P7EuQnGYTGqSvIZhLK1BQEtU6aK/KosTka3/AlR2snsYrqGbtyL5nw uzTQ9RZkUVV0/wahw6JAuZoBolIH4EGi/3X7/cVg+MG4q1Tphq5HTGCK++uu+5ogNgZX 5ixVX8NRm7DBfUXByBywrQkhHXIxMIOdbBbbqlhEyNtk+bvy+RW9yZEV2DyO/JIYJMh1 UQEvWRMt+uVCU6Gz2Vx/e48Ui19i//gjBrBxrNL/ANh7lYSa/2oOcn3eyR+orNJj7u37 Hg8GYfXuhKq6tfACePPi5vl+ipA2RO+uA3YxEd2hbpGeh9ygmNlPgLCN+hKojHcw3gmk Zsew==
MIME-Version: 1.0
X-Received: by with SMTP id uk5mr9136729pac.110.1369241323615; Wed, 22 May 2013 09:48:43 -0700 (PDT)
Received: by with HTTP; Wed, 22 May 2013 09:48:43 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <007501ce56f0$67f74080$37e5c180$> <> <> <>
Date: Wed, 22 May 2013 18:48:43 +0200
X-Google-Sender-Auth: ki20rsALVOkWXLS-bw324CYNQOI
Message-ID: <>
From: Simone Bordet <>
To: "John A. Tamplin" <>
Content-Type: multipart/alternative; boundary=047d7b111e83b4c10904dd5156c5
Cc: "" <>
Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 May 2013 16:50:22 -0000


On Wed, May 22, 2013 at 6:26 PM, John A. Tamplin <> wrote:
> 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 SPDY, the flow control had an initial window of 64k. This proved way too
small for uploads/downloads, which resulted in a 3x or more slowdown.
So there needs to be in ws a mechanism to configure this window (which SPDY
Turns out that now every client sends a huge initial window, so downloads
are now fast.
This of course impacts memory, since flow control is about memory, but
pretty much solved the flow control problem.

The next problem that arose was that now a stream/channel can take the
whole bandwidth and squat others channels.
So there is the need for a further flow control mechanism to prioritize
channels, that must be dynamic (i.e. changed during the transmissions of
SPDY is still discussing this, I am guessing it's also being discussed in
HTTP 2.0.

So "simple mux" looks like an oxymoron to me, and makes me wonder what
useful could be a ws mux solution that does not do dynamic channel
A typical use case Joakim presented to me was to tune video download rate
in a websocket server: a big priority initially to download faster than the
client video player plays, to make some buffer, and then reducing the
priority to a steady state with the video player's speed, or reducing
priority to almost zero if the user pauses the play.

Simone Bordet
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.