Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: curl websockets
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel F via curl-library <curl-library_at_cool.haxx.se>
Date: Wed, 23 Jun 2021 19:05:11 +0200
W dniu 2021-06-23 17:59, Felipe Gasper via curl-library napisał(a):
>> On Jun 23, 2021, at 11:23 AM, Daniel Stenberg via curl-library
>> <curl-library_at_cool.haxx.se> wrote:
>>
>> On Tue, 22 Jun 2021, Weston Schmidt via curl-library wrote:
>>
>>> I'm interested in feedback or suggestions for what/how to define a
>>> good websocket API that complements libcurl.
>>
>> My very simple idea on how it could be added to the API:
>>
>> 1. We add another value to set CURLOPT_CONNECT_ONLY to (2). If this is
>> used, and the URL is "http(s)://" then libcurl could "bootstrap" into
>> a websocket connection.
>>
>> 2. Once it is completed, we could have the application extract the
>> socket (to have something to wait on) and then use curl_easy_recv()
>> and curl_easy_send() to receive and send websockets data over that
>> connection.
>>
>> What would this be missing?
>
> There’d be want, IMO, for interfaces that differentiate
> sending/receiving full messages versus per-frame. (And, of course,
> sending text versus binary, *maybe* flexibly enough to accommodate
> potential new message types were that ever to happen.) And callbacks
> for multi-mode?
>
> Also the data from the close frame would probably be available via
> some new CURLINFO_* constants?
>
> A couple other notes (having written a full WS library and a Perl
> binding for another):
>
> - curl_easy_recv() would need either to poll under the hood or to do a
> socket timeout so that curl could send a ping if the local ping
> timeout happens midway through the recv.
>
> - WebSocket compression is a per-message affair: one message can be
> compressed while the next is uncompressed.
>
> - WS compression is also tunable; ideally those parameters should be
> configurable. (More specifically: WS’ deflate compression is tunable;
> any future compression schemes would probably also be.)
>
> I’m excited to see this!
>
> cheers,
> -Felipe
> -------------------------------------------------------------------
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
Please also add some way to set/get the Final bit for every websocket
message, in addition to control frame type (text/binary). This will help
to keep memory usage low and still be able to send/receive long WS
messages.
Daniel
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-06-23
Date: Wed, 23 Jun 2021 19:05:11 +0200
W dniu 2021-06-23 17:59, Felipe Gasper via curl-library napisał(a):
>> On Jun 23, 2021, at 11:23 AM, Daniel Stenberg via curl-library
>> <curl-library_at_cool.haxx.se> wrote:
>>
>> On Tue, 22 Jun 2021, Weston Schmidt via curl-library wrote:
>>
>>> I'm interested in feedback or suggestions for what/how to define a
>>> good websocket API that complements libcurl.
>>
>> My very simple idea on how it could be added to the API:
>>
>> 1. We add another value to set CURLOPT_CONNECT_ONLY to (2). If this is
>> used, and the URL is "http(s)://" then libcurl could "bootstrap" into
>> a websocket connection.
>>
>> 2. Once it is completed, we could have the application extract the
>> socket (to have something to wait on) and then use curl_easy_recv()
>> and curl_easy_send() to receive and send websockets data over that
>> connection.
>>
>> What would this be missing?
>
> There’d be want, IMO, for interfaces that differentiate
> sending/receiving full messages versus per-frame. (And, of course,
> sending text versus binary, *maybe* flexibly enough to accommodate
> potential new message types were that ever to happen.) And callbacks
> for multi-mode?
>
> Also the data from the close frame would probably be available via
> some new CURLINFO_* constants?
>
> A couple other notes (having written a full WS library and a Perl
> binding for another):
>
> - curl_easy_recv() would need either to poll under the hood or to do a
> socket timeout so that curl could send a ping if the local ping
> timeout happens midway through the recv.
>
> - WebSocket compression is a per-message affair: one message can be
> compressed while the next is uncompressed.
>
> - WS compression is also tunable; ideally those parameters should be
> configurable. (More specifically: WS’ deflate compression is tunable;
> any future compression schemes would probably also be.)
>
> I’m excited to see this!
>
> cheers,
> -Felipe
> -------------------------------------------------------------------
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
Please also add some way to set/get the Final bit for every websocket
message, in addition to control frame type (text/binary). This will help
to keep memory usage low and still be able to send/receive long WS
messages.
Daniel
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-06-23