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: About a websockets write callback
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Sat, 18 Jun 2022 12:58:40 +0200 (CEST)
On Fri, 17 Jun 2022, Dan Fandrich via curl-library wrote:
> I'm admittedly not very familiar with websockets, but would it make sense to
> move the abstraction up a layer? In other words, giving each web socket its
> own easy handle with its own set of websocket parameters.
That's already how it works. You'll setup a single easy handle for a single
websocket communication "channel".
> The different easy handles would be tied to a single web socket transport
> via a multi handle with curl handling the multiplexing of websocket data
> onto a single transport.
Sure. Even if I'm not doing websocket multiplexing (over the same connection)
in the first implementation step, you should still be able to do multiple
websocket transfers concurrently with libcurl using the multi interface.
That's one of the reaons I want to support the write callback way of
delivering websocket data so that an application quite easily can do many
concurrent websockets without threads.
> That way no extra data would need to be sent in each write callback; any
> such data would instead be tied to the easy handle. I don't know how often
> things like opcode would need to be changed, but they could be set on the
> appropriate handle using curl_easy_setopt whenever necessary.
The "ocode" is a websocket frame property so it can be different in every
single chunk of delievered payload, which is why applications needs to be able
to figure that out on a per callback invoke basis.
Date: Sat, 18 Jun 2022 12:58:40 +0200 (CEST)
On Fri, 17 Jun 2022, Dan Fandrich via curl-library wrote:
> I'm admittedly not very familiar with websockets, but would it make sense to
> move the abstraction up a layer? In other words, giving each web socket its
> own easy handle with its own set of websocket parameters.
That's already how it works. You'll setup a single easy handle for a single
websocket communication "channel".
> The different easy handles would be tied to a single web socket transport
> via a multi handle with curl handling the multiplexing of websocket data
> onto a single transport.
Sure. Even if I'm not doing websocket multiplexing (over the same connection)
in the first implementation step, you should still be able to do multiple
websocket transfers concurrently with libcurl using the multi interface.
That's one of the reaons I want to support the write callback way of
delivering websocket data so that an application quite easily can do many
concurrent websockets without threads.
> That way no extra data would need to be sent in each write callback; any
> such data would instead be tied to the easy handle. I don't know how often
> things like opcode would need to be changed, but they could be set on the
> appropriate handle using curl_easy_setopt whenever necessary.
The "ocode" is a websocket frame property so it can be different in every
single chunk of delievered payload, which is why applications needs to be able
to figure that out on a per callback invoke basis.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-06-18