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: Loïc 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
- Re: [hybi] The future of WebSockets, and the WiSH… Andy Green
- Re: [hybi] The future of WebSockets, and the WiSH… Andy Green
- Re: [hybi] The future of WebSockets, and the WiSH… Loïc Hoguin
- Re: [hybi] The future of WebSockets, and the WiSH… Anne van Kesteren
- Re: [hybi] The future of WebSockets, and the WiSH… Takeshi Yoshino
- Re: [hybi] The future of WebSockets, and the WiSH… Anne van Kesteren
- [hybi] The future of WebSockets, and the WiSH pro… Takeshi Yoshino
- Re: [hybi] The future of WebSockets, and the WiSH… Loïc Hoguin
- Re: [hybi] The future of WebSockets, and the WiSH… Andy Green
- Re: [hybi] The future of WebSockets, and the WiSH… Loïc Hoguin
- Re: [hybi] The future of WebSockets, and the WiSH… Greg Wilkins
- Re: [hybi] The future of WebSockets, and the WiSH… Andy Green
- Re: [hybi] The future of WebSockets, and the WiSH… Takeshi Yoshino
- Re: [hybi] The future of WebSockets, and the WiSH… Takeshi Yoshino
- Re: [hybi] The future of WebSockets, and the WiSH… Philipp Serafin
- Re: [hybi] The future of WebSockets, and the WiSH… Wenbo Zhu
- Re: [hybi] The future of WebSockets, and the WiSH… Tobias Oberstein