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: WebSocket feature request: is it possible to call write function when full frame is loaded only?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Richard Gray via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 8 Feb 2023 11:02:17 -0500
Daniel Stenberg via curl-library wrote:
> On Fri, 3 Feb 2023, Dmitry Karpov via curl-library wrote:
>
>> So, if we are talking about roadmap for future WebSocket features, I think
>> that the “message” level support and implementation should be the next step.
>
> I agree that it makes sense to rather deliver full messages than "just" full
> frames. It has the same challenge though: since frames can be ridiculously
> large, messages can be even larger. Do we have a set maximum limit or do we
> just allow any size up until malloc fails?
Seems to me that one way to deal with this would be some sort of overflow
indication that the application can act on by either continuing or erroring
out the transfer. That way huge buffers to handle the worst case scenario
don't have to be provided. Maybe there's a sneaky way to provide this in the
current read/write callbacks or maybe they could be provided by an extended
callback API. (curl 8?)
Rich
Date: Wed, 8 Feb 2023 11:02:17 -0500
Daniel Stenberg via curl-library wrote:
> On Fri, 3 Feb 2023, Dmitry Karpov via curl-library wrote:
>
>> So, if we are talking about roadmap for future WebSocket features, I think
>> that the “message” level support and implementation should be the next step.
>
> I agree that it makes sense to rather deliver full messages than "just" full
> frames. It has the same challenge though: since frames can be ridiculously
> large, messages can be even larger. Do we have a set maximum limit or do we
> just allow any size up until malloc fails?
Seems to me that one way to deal with this would be some sort of overflow
indication that the application can act on by either continuing or erroring
out the transfer. That way huge buffers to handle the worst case scenario
don't have to be provided. Maybe there's a sneaky way to provide this in the
current read/write callbacks or maybe they could be provided by an extended
callback API. (curl 8?)
Rich
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-02-08