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

Andy Green <andy@warmcat.com> Tue, 25 April 2017 12:06 UTC

Return-Path: <andy@warmcat.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 A0D6B12EC54 for <hybi@ietfa.amsl.com>; Tue, 25 Apr 2017 05:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBsV2TqupHQB for <hybi@ietfa.amsl.com>; Tue, 25 Apr 2017 05:06:40 -0700 (PDT)
Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC38012869B for <hybi@ietf.org>; Tue, 25 Apr 2017 05:06:39 -0700 (PDT)
To: =?UTF-8?Q?Lo=c3=afc_Hoguin?= <essen@ninenines.eu>
Cc: "hybi@ietf.org" <hybi@ietf.org>
References: <CAH9hSJYpnp0FXt9SsrujJM4OHcXe=pryUtHmM6dmcpgG67hdBw@mail.gmail.com> <CADnb78iPu7ACqZkYJ6SqceE2JNtV+y6M3ojT5PdGmDVoqZHsyQ@mail.gmail.com> <CAH9hSJZk-t-UwOD0jnaKr_M4uoHYwsCKU256ZsKxoVgwuWzxnQ@mail.gmail.com> <20c1e950-2c04-70eb-2372-bc9ba11c2de1@warmcat.com> <CADnb78iboXanrty==75B44AxGH7tCp1_d0yZcAYKKfjKGb0HbQ@mail.gmail.com> <30fe7e5c-fa63-cd49-9143-ae53d444e0bb@ninenines.eu> <4f7f43c3-7dae-19b4-a285-1409f8dd6ac2@warmcat.com> <5c6a07f6-5cc5-3f16-0c99-5cb7bd5e34ce@ninenines.eu>
From: Andy Green <andy@warmcat.com>
Message-ID: <b8863ce4-793e-39e5-a3a4-0c9f2f76cfb4@warmcat.com>
Date: Tue, 25 Apr 2017 20:06:01 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0
In-Reply-To: <5c6a07f6-5cc5-3f16-0c99-5cb7bd5e34ce@ninenines.eu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/YDJOrwFazRfcByAKyE1imFPLc9s>
Subject: Re: [hybi] The future of WebSockets, and the WiSH proposal
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 25 Apr 2017 12:06:41 -0000


On 04/25/2017 07:26 PM, Loïc Hoguin wrote:
> Might be clearer to say that my users generally want:
>
> * a standard solution (not reinvent the wheel)

Mmm I think everyone would say they prefer this.  But although the JS 
apis should stay the same, to some extent if we implement the wire 
protocol we can't have that because http/2 is nothing like http/1.

>
> * 1 always-on TCP connection

Yeah it is preferable.  Http/1 has gone away from that, in current 
browsers they don't even really do pipelining any more, eg Mozilla just 
shrugs and says use http/2 if you care about it.  (But they will say use 
http/1 if you want ws...)

>
> * binary events (not always required, sometimes just for efficiency 
> and/or convenience)
Yes, even original ws has this though.
>
> HTTP/2 + WiSH makes that possible.

OK... but http/2 brings most of what is needed including the mux.  I 
don't know what wish brings yet, but it will be a relatively small part 
of the puzzle from ws point of view.  Eg native http/2 framing for ws 
that they should have done in the first place would also completely 
deliver what you want by the sound of it.  There are definitely other 
ways of letting ws streams share http/2 links... wish or something else 
will ultimately be a political http/2 decision.

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

Yes you don't have to sell that to me at least, libwebsockets also has a 
lot of users using it as both ws client and server all over the shop.  
Recently since lws also handles client and server http[s] part of the 
job, there has been interest in http/2 support but it currently is 
meaningless for ws since no standardized way to carry it.

>
> 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.

So to be clear IIUI one of these TCP connections is the http one, and 
the TCP second connection is spawned by the stuff brought back by the 
first connection.

If http/2 guys had implemented ws transport on http/2 like they 
implemented everything else, this would be one TCP connection with two 
streams, and less roundtrip-times setting that up.  That's definitely 
what any future ws work should be aiming for.

>
>>> * 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.

I think it's out of scope, you yourself just said "my users generally 
want ... a standard solution".  For http and ws that means one or 
another standardized http and some way to upgrade a stream or connection 
to ws.

>
>>> * 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.

Yes ws/1 if we can call it that means one ws "connection" = one TCP 
connection.  But what we want to do is find an acceptable way to let ws 
flow as an http/2 stream.  So then the equivalent of ws BINARY stream 
will satisfy this IIUI.
>
>>> * 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.

Right... a lot of ws is just "long poll" and not actually intense... 
JSON is fine for both sides then.  If not, BINARY.

>
>>> * 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 
> non-standard.

I think this falls into DIY "subprotocol definition" envisaged by the 
original ws and is out of scope (or in some different scope).

Basically I think what you're saying boils down to you want 
ws-over-http/2 (I completely agree that is what is needed), and you 
think http/2 + wish will deliver that.  I already know http/2 will 
deliver 90%+ of it by itself, so no argument here up to the "http/2 +" 
part at least.

-Andy