> On Jul 2, 2021, at 5:53 PM, Daniel Stenberg <dan...@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
