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

[Loïc Hoguin <[e-mail]>]

Might be clearer to say that my users generally want:

* a standard solution (not reinvent the wheel)

* 1 always-on TCP connection

* binary events (not always required, sometimes just for efficiency 
and/or convenience)

HTTP/2 + WiSH makes that possible.

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

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.

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

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

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

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

-- 
Loïc Hoguin
https://ninenines.eu