> 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-boun...@lists.haxx.se> On Behalf Of Felipe Gasper via curl-library Sent: Monday, February 6, 2023 6:56 AM To: libcurl development <curl-library@lists.haxx.se> Cc: Felipe Gasper <fel...@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@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.html
