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: Nicolas Mora via curl-library <curl-library_at_cool.haxx.se>
Date: Fri, 2 Jul 2021 19:47:47 -0400
Le 2021-07-02 à 17 h 53, Daniel Stenberg via curl-library a écrit :
>>
>> 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.)
>
> "CURL_WS_MORE" is my currently suggested flag to say to libcurl that
> there's more data coming that belongs to the same data packet. Doesn't
> that work?
>
could libcurl wait for all the fragmented messages to arrive, then
concat them and serve the completed message to the calling application?
>> Alternatively, have separate curl_ws_send_text and curl_ws_send_binary
>> functions?
>
> That could certainly work and would save users sending text from having
> to set a "this is text" bit. My personal preference is to rather keep it
> to one function with the bits for type, but I'm here to listen in what
> peeps want and I will not push my own preferences if I'm in a minority.
>
Alternatively, a curl_ws_send_ping and curl_ws_send_pong would be useful.
Also, considering sending a pong response when a ping request is sent
automatically, unless it's specified by the calling program somehow.
>
> Yes, sorry I didn't even think about that. I'm positive users will
> immediately come up with use cases where they want 22 parallel websocket
> connections going on so they cannot block. Or perhaps we can offer some
> kind of blocking abilitites, but non-blocking is a must-support feature.
>
> Another thing that struck me is that we probably want to offer a decent
> way to do non-blocking ws-connects as well for the 22-connections user
> who won't accept that the application will block once for each setup...
>
Couldn't libcurl have both? a blocking and a non-blocking curl_ws_recv()
function?
>> 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.
>
> Yeah, that's one of my outstanding questions. How do we do that?
>
Using a callback function may be a solution, when a message is received,
libcurl calls a function specified by the application, something like
cur_ws_on_message_received()
/Nicolas
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-07-03
Date: Fri, 2 Jul 2021 19:47:47 -0400
Le 2021-07-02 à 17 h 53, Daniel Stenberg via curl-library a écrit :
>>
>> 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.)
>
> "CURL_WS_MORE" is my currently suggested flag to say to libcurl that
> there's more data coming that belongs to the same data packet. Doesn't
> that work?
>
could libcurl wait for all the fragmented messages to arrive, then
concat them and serve the completed message to the calling application?
>> Alternatively, have separate curl_ws_send_text and curl_ws_send_binary
>> functions?
>
> That could certainly work and would save users sending text from having
> to set a "this is text" bit. My personal preference is to rather keep it
> to one function with the bits for type, but I'm here to listen in what
> peeps want and I will not push my own preferences if I'm in a minority.
>
Alternatively, a curl_ws_send_ping and curl_ws_send_pong would be useful.
Also, considering sending a pong response when a ping request is sent
automatically, unless it's specified by the calling program somehow.
>
> Yes, sorry I didn't even think about that. I'm positive users will
> immediately come up with use cases where they want 22 parallel websocket
> connections going on so they cannot block. Or perhaps we can offer some
> kind of blocking abilitites, but non-blocking is a must-support feature.
>
> Another thing that struck me is that we probably want to offer a decent
> way to do non-blocking ws-connects as well for the 22-connections user
> who won't accept that the application will block once for each setup...
>
Couldn't libcurl have both? a blocking and a non-blocking curl_ws_recv()
function?
>> 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.
>
> Yeah, that's one of my outstanding questions. How do we do that?
>
Using a callback function may be a solution, when a message is received,
libcurl calls a function specified by the application, something like
cur_ws_on_message_received()
/Nicolas
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-07-03