WebSocket client API

[Joakim Erdfelt]

On Fri, Oct 9, 2015 at 8:07 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi Pavel, Simone,
>
> One way to make progress is to get the basic shape of the API agreed on
> without flow/resource management features. That probably represented the
> simplest form. I think we are very close to that.
>
> Then lets iterate from that form and consider the additional features
> (back-pressure and resource management), see how they fit or push/pull the
> basic shape in various directions, and importantly see what additional
> demands are imposed on the developer.
>

The backpressure situation for a framing protocol like WebSocket is a
different animal entirely vs more traditional streaming protocols like HTTP.
Whatever was come up with back in the HttpURLConnection days is irrelevant
today.
However, what you came up with for HTTP2 in the new HttpClient could be a
good candidate (if portable).

Techniques like Flow (reactive-streams) simplifies and solves most of these
issues in WebSocket.

The backpressure should be based on the feedback at the network level, not
the API, as there is almost never a 1::1 relationship of API call to
network websocket frame result (except for extremely small, non-extension
controlled, frames).   Extensions and auto-fragmentation (a requirement for
most of the WebSocket over HTTP2 proposals) mess with this in a large way.
Then there is also the interleaving of DATA vs CONTROL frames that can mess
with this backpressure behaviors as well.

Punting on backpressure is going to be a big mistake.
Every early implementation of WebSocket has suffered from this.
There are many rewrites, API breaking rewrites, underway (in many
implementations) to solve this.


> Also, I expect those features would need to be co-ordinated somewhat with
> the HTTP API to ensure a common pattern and possibly reuse of certain types.
>

WebSocket (currently) is an upgraded connection, once upgraded it is no
longer HTTP or follows any HTTP semantics.
Attempting to make it follow the HTTP connection behaviors is a mistake.

Now, that being said, once the WebSocket over HTTP2 specs settle down, then
this *might* be solved with the new HttpClient and its handling of HTTP2
specific streams (but this is a giant *IF* as there's 3 different proposals
for how to accomplish this, some using HTTP2 protocol directly, some using
tunneled behavior)

However, the existing HTTP/1.1 upgraded to WebSocket connection will likely
continue to be different behavior then what will come in the future.
The API for the WebSocket client should attempt to find a good middle
ground where the connection/framing behaviors are not hardcoded to assume
HTTP/1.1 or HTTP/2.

Even some of the assumptions in WebSocket currently (like no interleaved
TEXT vs BINARY messages) might be invalid in this future WebSocket over
HTTP2 world (one of the proposed solutions would utilize the built-in mux
of HTTP2 to fix this), then what will you do?

If you went with a Flow based solution then this nuance becomes irrelevant,
as its up to the connection type to determine behavior.



>
> --
>
> Regarding back pressure, i like what Michael/Pavel did with LongConsumer.
>
> Regarding resource management. This one is tricky. For HTTP Michael had a
> clever trick of piggy backing off the back pressure support, but i think
> that might be too clever as it is conflating two independent actions. I
> have a hunch that to do this effectively we may need some sort of resource
> supplier that is registered with the builder. That supplier defines the
> resource management strategy and requirements on a listener consuming
> resources (that is somewhat annoying because it couples the resource
> supplier with the listener).
>
> Paul.
>
>
I encourage you to implement now.
Don't wait for us.
Discover what we've been telling you quickly, the sooner the better, then
you'll be on-board with what we have been telling you.
We are quite confident of that.
Don't repeat the mistakes of the past (bad backpressure, send queues in
async, ignoring extensions, bad partial support, bad javadoc), don't
reinvent the wheel (untested backpressure techniques), use what you have
available to yourself (autobahn testsuite, Flow).

- Joakim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20151009/c9edf69c/attachment-0001.html>