Re: WebSocket2

Van Catha <> Thu, 13 October 2016 15:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3125E1298EB for <>; Thu, 13 Oct 2016 08:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.516
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b3Leljwozh4H for <>; Thu, 13 Oct 2016 08:24:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C11D6129568 for <>; Thu, 13 Oct 2016 08:24:58 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1buhoW-0004cc-SP for; Thu, 13 Oct 2016 15:20:56 +0000
Resent-Date: Thu, 13 Oct 2016 15:20:56 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1buhoS-0004bB-CC for; Thu, 13 Oct 2016 15:20:52 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1buhoP-0001eQ-IK for; Thu, 13 Oct 2016 15:20:50 +0000
Received: by with SMTP id f6so50905709qtd.2 for <>; Thu, 13 Oct 2016 08:20:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id f12mr7227428qtf.123.1476372023667; Thu, 13 Oct 2016 08:20:23 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 13 Oct 2016 08:20:22 -0700 (PDT)
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3766E4A0@bgb01xud1012>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <7CF7F94CB496BF4FAB1676F375F9666A3766E4A0@bgb01xud1012>
From: Van Catha <>
Date: Thu, 13 Oct 2016 11:20:22 -0400
Message-ID: <>
To: Lucas Pardue <>
Cc: Takeshi Yoshino <>, Kari Hurtta <>, Ilari Liusvaara <>, HTTP working group mailing list <>
Content-Type: multipart/alternative; boundary=001a113bff3e06f899053ec0a658
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Scan-Sig: 1buhoP-0001eQ-IK c0faf976a09c4c569ad3a6adec254025
Subject: Re: WebSocket2
Archived-At: <>
X-Mailing-List: <> archive/latest/32579
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-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 +
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
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
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
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
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
on the server side (not in the case of RFC7692 deflate). If there would be
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.

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.