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: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 6 Feb 2023 21:44:17 +0000
> I’d say make it tunable, with a reasonable default. If a message exceeds that maximum, close the connection with code 1009.
Yes, I agree. This would be the right approach.
I saw WebSocket server implementations which used one-message=one-frame approach.
They had hard limits on how big their messages could be and didn't allow very large messages.
For such implementations, very large messages using very large frames become impractical at some sizes, because they couldn't properly send/receive controls messages while large frame transfers are still in progress.
More practical implementations allow frames to grow up to some limit, and then apply fragmentation on large messages.
Thanks,
Dmitry Karpov
-----Original Message-----
From: curl-library <curl-library-bounces_at_lists.haxx.se> On Behalf Of Felipe Gasper via curl-library
Sent: Monday, February 6, 2023 6:56 AM
To: libcurl development <curl-library_at_lists.haxx.se>
Cc: Felipe Gasper <felipe_at_felipegasper.com>
Subject: [EXTERNAL] Re: WebSocket feature request: is it possible to call write function when full frame is loaded only?
> On Feb 6, 2023, at 2:57 AM, Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se> 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?
I’d say make it tunable, with a reasonable default. If a message exceeds that maximum, close the connection with code 1009.
-FG
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Date: Mon, 6 Feb 2023 21:44:17 +0000
> I’d say make it tunable, with a reasonable default. If a message exceeds that maximum, close the connection with code 1009.
Yes, I agree. This would be the right approach.
I saw WebSocket server implementations which used one-message=one-frame approach.
They had hard limits on how big their messages could be and didn't allow very large messages.
For such implementations, very large messages using very large frames become impractical at some sizes, because they couldn't properly send/receive controls messages while large frame transfers are still in progress.
More practical implementations allow frames to grow up to some limit, and then apply fragmentation on large messages.
Thanks,
Dmitry Karpov
-----Original Message-----
From: curl-library <curl-library-bounces_at_lists.haxx.se> On Behalf Of Felipe Gasper via curl-library
Sent: Monday, February 6, 2023 6:56 AM
To: libcurl development <curl-library_at_lists.haxx.se>
Cc: Felipe Gasper <felipe_at_felipegasper.com>
Subject: [EXTERNAL] Re: WebSocket feature request: is it possible to call write function when full frame is loaded only?
> On Feb 6, 2023, at 2:57 AM, Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se> 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?
I’d say make it tunable, with a reasonable default. If a message exceeds that maximum, close the connection with code 1009.
-FG
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-02-06