Re: [hybi] The future of WebSockets, and the WiSH proposal

Loïc Hoguin <> Tue, 25 April 2017 11:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E94212EC02 for <>; Tue, 25 Apr 2017 04:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.699
X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wiw4-5t1FFf7 for <>; Tue, 25 Apr 2017 04:28:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB93A129ADF for <>; Tue, 25 Apr 2017 04:28:01 -0700 (PDT)
Received: from [] ([]) by (mreue101 []) with ESMTPSA (Nemesis) id 0MYekE-1cXdzn2ND0-00VTW7; Tue, 25 Apr 2017 13:27:53 +0200
To: Andy Green <>
References: <> <> <> <> <> <> <>
Cc: "" <>
From: =?UTF-8?Q?Lo=c3=afc_Hoguin?= <>
Organization: Nine Nines
Message-ID: <>
Date: Tue, 25 Apr 2017 13:26:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:ZVBnY6JRC26KFILrAhjBc9w7UJNCdHtJdK1k2vDGNj9OuX5zvQy iSLA/UgGIOtHKz57K3mZwVHR74tlAC6mHLku1PlSE24EZaUaVr7xLMyz/DqqKcay+8wqb4m KQhCS8CJ9I58OlqvD4u7bHTJJHiVI2L3rt/ov4SfwwCjHo3DHb5ABtFYq9uJ6mDsPLiGItl ytHezM++SlXWS/2pXx7Lg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:h6TQELlzEjM=:wANq0ePFyjhwWG62Mqf2j8 X5KwltszJGUglZT4sXFW1x1BQyG2n1NNwaiZKPldigRq/7c3dJTQphBHWbOYR7LgcjfPfjpKk O1F7yv68IuavHkYoU6kb+rdbiAbInJPKUjVKAhF+jEQwuph28hrTUzilnBLrQYbALlrTo/2ru OK0f27lFkPmDKPusb7OtOisjPApJOFd5tcDEH50n3YsmLtiWJJW1DOFw3YkYcCQoPhPzOUMPZ nrQE0UKvGJ1JtlZP4PMplsBVvITuUcyDTEUE9dpTV6PGrUUV+nQfXg84B1SbP10ovPDxUerdS I3lP5tb60IUcqChjUZah9IZtN9vWuJTpmDBQEaeEuEZTxgBbJShGTZ9BoFIVfALXw3IxEQWe3 exERSywmYc4iyRTF3oeUmUuL34e0VQmj8GmbgyhA4oogbB8puPdP21I5JLdg6lL2ofrAvgGeI CliKCNw9KBZFnz9BiI0j1GiZrBif2sUYcs088Cfs33mFu13syDIIthSrhmCmJ2Dl/2jUKrqLk SlXzJcJKajEmVHeEajdeGXqcBFRynbVtf8A7IG+8UsI7wlPvVEaa/fxViy9AoX2sA+U1SRJbs jI5aEzRGLzmZuUZiQ7yH0nu21m7nJSIr+pHO6wCp88Df4gyXPGrTXFLYKoWlYYkeCRAYOZCdW xWHFdBDYiulM8p2cy65DC0xArGKsg4UtkWJSQi5Y5wCGlDKSV1jd5vw4iZNPJX7yzY4hN02EO VSMzWRqDyz08++YU
Archived-At: <>
Subject: Re: [hybi] The future of WebSockets, and the WiSH proposal
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Apr 2017 11:28:04 -0000

Might be clearer to say that my users generally want:

* a standard solution (not reinvent the wheel)

* 1 always-on TCP connection

* binary events (not always required, sometimes just for efficiency 
and/or convenience)

HTTP/2 + WiSH makes that possible.

Applications are (soft) realtime systems (messaging, games, IoT 
networks, databases and more).

All these are different solutions that my users have used, none of which 
are satisfactory. They are mostly independent. I'll make clear the 
issues for each case.

On 04/25/2017 12:47 PM, Andy Green wrote:
>> A common pattern my users have when contacting a server is to first
>> request a resource that will stream events, then perform other
>> requests separately.
>> Here are the issues commonly encountered right now. I'm assuming here
>> that clients can use HTTP/2:
>> * Having to open 2 connections (not the best idea for mobile clients,
>> and uses twice the memory on the server side)
> You mean two TCP connections?
> Why?  You mean fetching the html that has the scripts and then the
> scripts opening the ws connection?

Two TCP connections yes, because the clients need to receive events as 
soon as they occur on the server, and as far as standards are concerned 
there's only Websocket and text/event-stream allowing this, and only 
Websocket is efficient with binary data.

>> * Having to reimplement a custom HTTP/2-like protocol on top of
>> Websocket to avoid having those 2 connections (works, but
>> non-standard, and prone to errors)
> Eh... what did you mean then "two connections"?

That's a separate solution that allows only one connection, but is 
completely non-standard and requires implementing in all languages involved.

>> * Having to use text/event-stream with base64-encoded binary data
>> (inefficient, especially for larger events)
> What's up with ws BINARY?

It's perfect! But requires a separate connection.

>> * For users who would otherwise be fine with text-based events: having
>> to use text encodings. JSON in particular is very inefficient and puts
>> a heavy strain on the server, switching from JSON to msgpack for
>> example makes my servers load go back to 0 even with tens of thousands
>> of connections. Even if using something other than JSON, there's still
>> the matter of decoding text/event-stream.
> ... JSON can make a lot of sense when things are less intense. What's up
> with BINARY ws connections though?

I usually recommend to start with JSON because it's the simplest to go 
with, and only replace it with something else when necessary. It often 
becomes necessary. That's probably not the case in general though.

>> * Having to implement a custom multipart media type for events, for
>> those who go that route. Few do because it's non-standard.
> Can you explain what this means?  It sounds kind of specific to whatever
> it is you are doing.

It's yet another solution allowing a single solution, but again 

Loïc Hoguin