Re: WebSocket2

Van Catha <vans554@gmail.com> Thu, 13 October 2016 15:25 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3125E1298EB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 13 Oct 2016 08:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.516
X-Spam-Level:
X-Spam-Status: No, score=-9.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 b3Leljwozh4H for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 13 Oct 2016 08:24:58 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C11D6129568 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 13 Oct 2016 08:24:58 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1buhoW-0004cc-SP for ietf-http-wg-dist@listhub.w3.org; Thu, 13 Oct 2016 15:20:56 +0000
Resent-Date: Thu, 13 Oct 2016 15:20:56 +0000
Resent-Message-Id: <E1buhoW-0004cc-SP@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <vans554@gmail.com>) id 1buhoS-0004bB-CC for ietf-http-wg@listhub.w3.org; Thu, 13 Oct 2016 15:20:52 +0000
Received: from mail-qt0-f170.google.com ([209.85.216.170]) by maggie.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <vans554@gmail.com>) id 1buhoP-0001eQ-IK for ietf-http-wg@w3.org; Thu, 13 Oct 2016 15:20:50 +0000
Received: by mail-qt0-f170.google.com with SMTP id f6so50905709qtd.2 for <ietf-http-wg@w3.org>; Thu, 13 Oct 2016 08:20:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CvcNdw2RzjpFUMQ/i05xTdZMxQOmmXvVCHaS9ljGSSg=; b=LT32FfLkenwU5J7MUV8BfxDOttfTOnKZQS2leyZFvHhAn1Bdse5g58n+gz9C4Rwy+T g3v38uXYqQTOA0/bGkhLWeqTavKSA/G0vjJUC4xL5wqb5CldQvwoIy5pVwHLyraytkCU giD5+XCJa+XMYkfYNJYxXX3LmFePxHx5JKqzYAs7R7UkcMB8Cpklgp0/aE5ipE4gggV6 l1IpwVRZUJcYYmvrRqxLPJyPZh6FwicIsh1VNbhe3oI4KYtyi6C9eWYyhcHUY3SSpGkR 7Jr6DOZXzp1Z6fdeZTvmczrfp8UiGmfKSZqO0pyqmlBvg1ZfQyR5TE/KJUwglwq6Tzpp hUew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CvcNdw2RzjpFUMQ/i05xTdZMxQOmmXvVCHaS9ljGSSg=; b=Mw5KVwgJgQvRk0NhqHvyFlvJkaZ2Vivv1/b8s4jGkfvY3qywZs3rd0xcNm8AQHYmCh dnnibNcv0NSLyGWEulyqJD/uaUofCNqcTp2+hmeFh+7eauiPeeUNB4ieMmXR5aFwez9z qZfMEJT7jhAnDRW5yv1sXQBUCAJRVP91unSjCvjEkvSsLw5LFXHkA5Qy9GAwqV3AljAr ZtV3O0Nd+j5SYWRAJaVcKPM5xEce5lFTw1wt5qHCO9aVWZwnRDAAvZwhqxCdihng+DC2 +fjHpvDz3EkHjWTwNWegbzJfhSgqfRl17BFgb2kcUMKfQzkxmMlrRzP1lCUo8NbOiioG jVqA==
X-Gm-Message-State: AA6/9RlLJXz1MQw44QV8IYuSR5Drv0/lj4gjW9dPEQTcN+7RNqSM9bkqBomze8dm92bbIUhKqy+A795kD4OA3w==
X-Received: by 10.200.37.204 with SMTP id f12mr7227428qtf.123.1476372023667; Thu, 13 Oct 2016 08:20:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.217.206 with HTTP; Thu, 13 Oct 2016 08:20:22 -0700 (PDT)
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3766E4A0@bgb01xud1012>
References: <CAG-EYChPJpAzoEuNwY3cNz503d0FRbNnDx_9AsNsZyfb5nmN0g@mail.gmail.com> <20161002080030.5F328160CC@welho-filter4.welho.com> <20161002101548.GA9450@LK-Perkele-V2.elisa-laajakaista.fi> <201610021110.u92BAWpi019029@shell.siilo.fmi.fi> <20161002124346.GB9450@LK-Perkele-V2.elisa-laajakaista.fi> <201610021340.u92DeBBL029907@shell.siilo.fmi.fi> <20161002171905.GA10108@LK-Perkele-V2.elisa-laajakaista.fi> <201610030440.u934e3kL031002@shell.siilo.fmi.fi> <CAG-EYCgEs1oSdLeLVwd12ECaL=+3pzytuy89xFWvvKCEY8fi4g@mail.gmail.com> <CAH9hSJaMsKaoTK+kr2X_GP_T7=jcDQtFLSusYrV+nDWCadcyxg@mail.gmail.com> <201610041520.u94FK6vV008976@shell.siilo.fmi.fi> <CAH9hSJY40AnYE1JTuc1aYFzRtaT-+PwX8M7YeVj2cbosCfD0TQ@mail.gmail.com> <CAG-EYCiCkC2XWuhbOtwKusW28=p-sYLArDR6MfN1Zc41+9f2-A@mail.gmail.com> <7CF7F94CB496BF4FAB1676F375F9666A3766E4A0@bgb01xud1012>
From: Van Catha <vans554@gmail.com>
Date: Thu, 13 Oct 2016 11:20:22 -0400
Message-ID: <CAG-EYCiyba-3uszv=z3bRH5v+YVUo-3J=w-QC5n_3+OC-y0ybg@mail.gmail.com>
To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
Cc: Takeshi Yoshino <tyoshino@google.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Ilari Liusvaara <ilariliusvaara@welho.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a113bff3e06f899053ec0a658
Received-SPF: pass client-ip=209.85.216.170; envelope-from=vans554@gmail.com; helo=mail-qt0-f170.google.com
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Hub-Spam-Report: AWL=-1.138, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1buhoP-0001eQ-IK c0faf976a09c4c569ad3a6adec254025
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WebSocket2
Archived-At: <http://www.w3.org/mid/CAG-EYCiyba-3uszv=z3bRH5v+YVUo-3J=w-QC5n_3+OC-y0ybg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32579
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

> As I explained privately a bit, we're developing the Fetch API and the
> Streams API for the web platform to allow for using bidirectional byte
> stream over HTTP (over TCP, HTTP2, QUIC, ...). The transform stream
> allows for implementing e.g. JSON stream parser/serializer, deflate
> codec (like RFC7692), etc. either in JavaScript or as standardized
> web API implemented in C++, etc., and connecting them to flow data
> efficiently (transfer offloading). This is the story behind the
> WiSH proposal for web browsers. I'm going to explain this more in
> the introduction section of the I-D. Not only Chrome but some other
> vendors are also showing support, experimenting and shipping some of
> them. This might work for your needs.

I am very interested in the Streams API and would even like to contribute,
but I see it as a long road ahead with many questions.  First there is no
framing so how do you handle compression? Ideally with something like
Streams API, you want javascript inbrowser to expose the C++ level RFC7692
deflate/inflate, then you can have full control of your framing +
compression.
I like this scenario the most.  Otherwise Streams API will just turn into
another mutated WebSockets, which sacrificed correctness for simplicity to
developers that know little about writing network services.  I hope the
future
will not follow in these footsteps.

Also LZ4 with levels 1 and 9 I think should be highly considered to be
added as
a compression method alongside of RFC7692.

Google Chrome solved a lot of performance problems with NaCl and hopefully
that will be merged into Chromium soon.  I can see NaCl doing a lot
of the heavy lifting related to Streams API like decoding/encoding protobuf
or even a bitserialized protocol. The possibilities with simple 2 ways
streams
will be endless.

A lot of enterprise rely on NaCl for their B2B and B2C apps.

This NaCl bit is to mention how the future is moving towards C/C++ in the
browser,
so Javascript performance for things like encryption/compression should be
downplayed when considering whether to bake things into the API.

> What did you mean by "to use a defined amount of bits for the lengths"?
> Imposing the limit in the form of the value in the field which specifies
> the length of the payload length field?

I mean that if you only have 32 bits for length the maximum value you can
represent is 4.3~ billion.  Cut that down to 24 bits and its 16~ million.
So you can limit the max framesize from 4.3~ gigabyte to 16~ megabyte by
simply
reducing the amount of bits used for the frame length.

> Did you mean turning on / off LZ4 using the 2 RSV bits?

Yea exactly. It adds a little flexibilty and removes the need to keep a
state
on the server side (not in the case of RFC7692 deflate). If there would be
a
use case for that.  The main benefit I see is if you do not want to
compress small messages say under 20 octets in length.

I updated the RFC for WebSocket2 over HTTP/2 if anyone wants to take another
look, it now has a more solid handshake and a few tweaks to the wire format.

https://github.com/vans163/websocket2-drafts/blob/master/websocket2-over-http2.txt

I still want to push for this WebSocket2 because already the internet runs
on WebSocket, and this will be a smooth transition.

I do believe thought that a Steams API with pure 2 way binary streaming (no
compression, no framing) with C/C++ compressor exposed
through Javascript browser API is the distant future.