Re: more WebSockets

From: Weston Schmidt via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 12 Aug 2021 00:11:46 -0700

>> Other websockets implementations are doing that then I presume?

I'll only speak to my implementation ... I provided both a streaming
interface and a block/message interface. The block/message is nice
for small stuff if you know limits but, for all the reasons you point
out, streaming through a library is safer & then delegate to the app
to assemble. Streaming is also simpler when you need to deal with how
non-aligned UTF8 encoded text is handled. A few extra callbacks with
small bits of text can reduce larger allocations, copies, or buffers
that have reserved padding at the start to handle when you have to
carry over a single 4 byte character at the start of a block of text.

I like the proposal Daniel. The few thoughts I have:

For the easy interface I'm not sure how valuable the curl_ws_poll()
call will be. I like the simplicity of just tx and rx. That seems
pretty useful for several simple cases. If you're doing more than
that you probably are going to want the flexibility of multi.

I'd like to add a flag to CURLOPT_WS_OPTIONS that tells curl if it
should negotiate compression or not for easy & multi. This allows
users to negotiate their own subprotocols where compression may not be
allowed and instruct curl to play nicely. Also, for debugging
purposes this would be nice.

I like the automatic response to pings & pongs by default. Perhaps
another CURLOPT_WS_OPTIONS flag might disable the automatic response
behavior in the cases where an app doesn't want to respond (or delay
the response, etc). Since pings and pongs are allowed to contain
application data, it would be useful to send that through the
CURL_WS_WRITE callback with a CURLWS_PING or CURLWS_PONG flag so the
application gets the payload data. The ability for a client to
initiate a ping with it's own arbitrary data is valuable as that
enables bidirectional health checking of a connection at the
application layer.

Pings can be effectively used for all sorts of interesting out of band
data while large transfers are happening.

Wes

On Wed, Aug 11, 2021 at 11:50 PM Daniel Stenberg via curl-library
<curl-library_at_cool.haxx.se> wrote:
>
> On Wed, 11 Aug 2021, Felipe Gasper wrote:
>
> >> When a single frame can be 61 bits large?
>
> (Of course I meant 63...)
>
> And thanks for this. As you know I'm a WebSockets rookie so I need and
> appricate pointers like this!
>
> > I believe most implementations enforce a maximum message length. Mojolicious
> > (Perl), for example, stipulates 256 KiB by default.
> > (https://metacpan.org/pod/Mojo::Transaction::WebSocket#max_websocket_size) I
> > think Firefox is 2 GiB.
>
> It could of course work to have a maximum message size set, but this makes me
> curious. Surely a client will run into problems if you use 256KB max size
> against a server-side websocket thing that assumes much larger?
>
> Using up to 2 gigabytes buffer for a single message is still several
> magnitudes larger than I would want libcurl to do.
>
> Other websockets implementations are doing that then I presume?
>
> --
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html
> -------------------------------------------------------------------
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-08-12