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: Sat, 3 Jul 2021 06:33:17 -0400
> On Jul 2, 2021, at 5:53 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Fri, 2 Jul 2021, Felipe Gasper wrote:
>
>>> 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.)
>
> "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?
>
> And if doesn't work, can't we just invent flags to make a way that works?
I was being overly literal; consider:
1. TEXT | MORE
2. <no flag>
Here the continuation (#2) is “non-specified”; the frame that has MORE on it is actually the one that defines the data type.
But, if it were *just* frame #2, with no frame #1, that would mean a standalone binary frame.
If flags are the preference then maybe have a separate BINARY flag, and implement sanity-checking that rejects misuse (e.g., TEXT | BINARY, continuation with no preceding data type, etc.)
>
>>> 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?
>
> 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...
Agreed; non-blocking connect will be desirable.
Even non-22-connect apps may combine plain HTTP, D-Bus, database, etc. all under a single event loop.
>
>> 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?
>
> For CONNECT_ONLY, libcurl allows the application to extract the socket for the transfer so that it can select() on it, but I have a feeling that's a little too raw here. We might need to provide a function for this purpose. curl_ws_poll() maybe. It needs some further thinking.
I would think this could just plug into multi. So whatever apps are doing to poll now would work with WS.
That seems easier if receive is implemented as a callback since there’s one fewer place that has to muck with polling.
>
> That said, providing allocated memory blocks to the application is a rather quirky (and unusual) way to deliver data and it doesn't sit very well with me.
Libwebsockets may offer a useful comparison:
https://libwebsockets.org/git/libwebsockets/tree/minimal-examples/ws-client
> We could also just return a bit (CURL_WS_FRAG) in the 'recvflags' which means it was only a fragment and that it needs to call the recv function again to get the next piece of the data.
Note that, for compression, the RFC stipulates that all of the frames of a given message need to be concatenated before delivery to the application. That’s how the browser API works: the application doesn’t see individual frames, just entire messages.
In practice, I don’t know how necessary that is--Libwebsockets seems not to work that way--but it’s worth considering.
-F
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-07-03
Date: Sat, 3 Jul 2021 06:33:17 -0400
> On Jul 2, 2021, at 5:53 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Fri, 2 Jul 2021, Felipe Gasper wrote:
>
>>> 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.)
>
> "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?
>
> And if doesn't work, can't we just invent flags to make a way that works?
I was being overly literal; consider:
1. TEXT | MORE
2. <no flag>
Here the continuation (#2) is “non-specified”; the frame that has MORE on it is actually the one that defines the data type.
But, if it were *just* frame #2, with no frame #1, that would mean a standalone binary frame.
If flags are the preference then maybe have a separate BINARY flag, and implement sanity-checking that rejects misuse (e.g., TEXT | BINARY, continuation with no preceding data type, etc.)
>
>>> 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?
>
> 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...
Agreed; non-blocking connect will be desirable.
Even non-22-connect apps may combine plain HTTP, D-Bus, database, etc. all under a single event loop.
>
>> 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?
>
> For CONNECT_ONLY, libcurl allows the application to extract the socket for the transfer so that it can select() on it, but I have a feeling that's a little too raw here. We might need to provide a function for this purpose. curl_ws_poll() maybe. It needs some further thinking.
I would think this could just plug into multi. So whatever apps are doing to poll now would work with WS.
That seems easier if receive is implemented as a callback since there’s one fewer place that has to muck with polling.
>
> That said, providing allocated memory blocks to the application is a rather quirky (and unusual) way to deliver data and it doesn't sit very well with me.
Libwebsockets may offer a useful comparison:
https://libwebsockets.org/git/libwebsockets/tree/minimal-examples/ws-client
> We could also just return a bit (CURL_WS_FRAG) in the 'recvflags' which means it was only a fragment and that it needs to call the recv function again to get the next piece of the data.
Note that, for compression, the RFC stipulates that all of the frames of a given message need to be concatenated before delivery to the application. That’s how the browser API works: the application doesn’t see individual frames, just entire messages.
In practice, I don’t know how necessary that is--Libwebsockets seems not to work that way--but it’s worth considering.
-F
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-07-03