>> 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@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
