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: Felipe Gasper via curl-library <curl-library_at_cool.haxx.se>
Date: Fri, 2 Jul 2021 09:42:11 -0400
> On Jul 2, 2021, at 7:40 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Fri, 2 Jul 2021, Felipe Gasper wrote:
>
> Thanks!
>
>> The send interface could look much like curl_easy_send():
>>
>> curl_ws_send( easy, buffer, buflen, &sent, enum curl_ws_message_type type, enum curl_ws_flags flags )
>
> Or perhaps with the type and flags just made as a single bitmask.
This will make it impossible to specify a continuation frame rather than a data frame. (Context: when a message is fragmented, the message’s first frame is text/binary, and the latter ones are continuation.)
That may be OK if curl will commit to abstracting that distinction away.
Also, if WS were to add a 3rd data type -- e.g., via some extension -- then it would be possible to specify CURL_WS_TEXT | CURL_WS_FANCY_NEW_EXT_TYPE, which means curl would need to detect that.
Alternatively, have separate curl_ws_send_text and curl_ws_send_binary functions?
>
>> Most WS libraries that I’ve seen implement reception as a callback, with a separate control to pause reception of incoming messages.
>
> I won't say that's wrong, but I don't see how a callback helps with this API.
>
> curl_ws_recv() could just be made to not return until the entire packet can be returned. Or with an option to return a partial one.
I assume you mean something like EAGAIN rather than actually blocking?
Having the caller call curl_ws_recv() directly would mean that that same caller would need to know when the socket has data to read. I don’t know if that’s always a safe assumption.
Also, WS includes ping/pong, so even if the socket has data there might not be any application-level data incoming. (Ping/pong isn’t usually exposed to the application.)
> An area for consideration is how to deal with the buffer (size). I mean, if it wants to wait for a full packet to arrive I suppose it can be large and it might not fit in the user-provided buffer, so the application would need to call it multiple times do drain the data.
Would this argue in favour of a callback, then? Curl could just allocate as it knows it needs. The caller, then, could either memcpy or assume ownership of the buffer (by, e.g., returning CURL_WS_NOFREE from the callback).
Alternatively, there is precedent here with SOCK_SEQPACKET sockets, though curl has the ability to deliver what IMO would be a smoother interface.
>
> I took the liberty of jotting down some of these API thoughts in the wiki page. Still incomplete and not really functional, but I figured it could help to stir up our collective minds..
>
> https://github.com/curl/curl/wiki/WebSockets#api
I feel funny asking this, but is there a comment feature in this wiki system? I don’t see such, but it would seem useful.
-FG
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-07-02
Date: Fri, 2 Jul 2021 09:42:11 -0400
> On Jul 2, 2021, at 7:40 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Fri, 2 Jul 2021, Felipe Gasper wrote:
>
> Thanks!
>
>> The send interface could look much like curl_easy_send():
>>
>> curl_ws_send( easy, buffer, buflen, &sent, enum curl_ws_message_type type, enum curl_ws_flags flags )
>
> Or perhaps with the type and flags just made as a single bitmask.
This will make it impossible to specify a continuation frame rather than a data frame. (Context: when a message is fragmented, the message’s first frame is text/binary, and the latter ones are continuation.)
That may be OK if curl will commit to abstracting that distinction away.
Also, if WS were to add a 3rd data type -- e.g., via some extension -- then it would be possible to specify CURL_WS_TEXT | CURL_WS_FANCY_NEW_EXT_TYPE, which means curl would need to detect that.
Alternatively, have separate curl_ws_send_text and curl_ws_send_binary functions?
>
>> Most WS libraries that I’ve seen implement reception as a callback, with a separate control to pause reception of incoming messages.
>
> I won't say that's wrong, but I don't see how a callback helps with this API.
>
> curl_ws_recv() could just be made to not return until the entire packet can be returned. Or with an option to return a partial one.
I assume you mean something like EAGAIN rather than actually blocking?
Having the caller call curl_ws_recv() directly would mean that that same caller would need to know when the socket has data to read. I don’t know if that’s always a safe assumption.
Also, WS includes ping/pong, so even if the socket has data there might not be any application-level data incoming. (Ping/pong isn’t usually exposed to the application.)
> An area for consideration is how to deal with the buffer (size). I mean, if it wants to wait for a full packet to arrive I suppose it can be large and it might not fit in the user-provided buffer, so the application would need to call it multiple times do drain the data.
Would this argue in favour of a callback, then? Curl could just allocate as it knows it needs. The caller, then, could either memcpy or assume ownership of the buffer (by, e.g., returning CURL_WS_NOFREE from the callback).
Alternatively, there is precedent here with SOCK_SEQPACKET sockets, though curl has the ability to deliver what IMO would be a smoother interface.
>
> I took the liberty of jotting down some of these API thoughts in the wiki page. Still incomplete and not really functional, but I figured it could help to stir up our collective minds..
>
> https://github.com/curl/curl/wiki/WebSockets#api
I feel funny asking this, but is there a comment feature in this wiki system? I don’t see such, but it would seem useful.
-FG
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-07-02