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: more WebSockets
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 12 Aug 2021 09:12:51 +0200 (CEST)
On Wed, 11 Aug 2021, Dmitry Karpov via curl-library wrote:
Thanks for the feedback, this is very helpful!
> From a brief look at the document, it looks like Curl will provide only
> WebSocket frame level of communication, so the client will have to implement
> full message assembling itself.
If you by "assembling" mean concatenating multiple frames until the FIN frame,
then my thinking was yes, so that we wouldn't have to buffer up potentially a
large amount of data before passing it on.
How do other client implementations work and how do they handle the unlimited
message size? Should we just impose our own maximum size and have applications
raise it when needed?
> If my understanding is correct, then it seems like a good initial approach
> to me - it handles the most critical WS steps: WS handshake, frame
> sending/receiving and error reporting, even though it leaves WS message
> layer communication (sending/receiving full message) to the clients.
That's my current thinking, yes.
I want the API to be "good enough" to get sufficiently advanced websockets
communication going against "most" server-side websockets implementations.
When we think it is, we can start working on code to make it real and then see
how it actually works with some early test client applications. The feature
will be marked EXPERIMENTAL until we deem it ready anyway so there will be
wiggle room to change things around all the way through until we decide it is
fine enough to carve in stone (and ship enabled by default in a release).
> As it was mentioned in some of our WS-related discussions, the WS message
> layer is more complex than the framing layer
Can you elaborate on this? Aren't ws messages just the payload from N frames
concatenated and delivered?
I know there can be control frames injected in the middle of stream of data
frames, but the only standard such frames are close, ping and pong and I
imagine libcurl would handle them and thus what is passed on to the client
would be an unbroken stream of data frames.
> libcurl should provide a way to the client to handle incoming message data.
> This means that besides Frame-based "send/receive" callbacks, as described
> in the document, there should be message-based callbacks on top of the
> Frame-layer, which would allow clients to work with WS messages, rather than
> with WS frames.
There's no way then for libcurl to avoid having to buffer the entire ws
message, right?
> A small note about iflags:
>
> " iflags is a bitmask featuring the following (incoming) flags:
> CURLWS_TEXT - this is text data
> CURLWS_BINARY - this is binary data
> CURLWS_FIN - this is also the final fragment of a message
> CURLWS_CLOSE - this transfer is now closed"
>
> The "Text" and "Binary" are special WS frame/message opcodes, so it is
> probably better to distinguish frame flags and the frame opcodes instead of
> mixing them together.
This has been mentioned before but I don't understand why.
Why does it matter to an application exactly how the information arrived? The
application doesn't see the websocket protocol and it doesn't have to know
much about it using this API.
> If client is supposed to handle WS frames it gets from libcurl, then it
> needs to know the precise opcode along with the frame flags, so it can
> properly handle cases when "control" and "data" frames from different
> messages are intermixed (i.e. one large "data" messages intermixed with many
> "control" messages) and when some "custom" opcodes are used for some
> proprietary WS communications.
To me, that sounds like an argument for providing all the opcodes through to
the application. I didn't understand that they are actually used like that,
especially not within the same message.
Can opcode 3-7 and b-f be used "at will" by implementations to signal
something without negotiating an extension?
Date: Thu, 12 Aug 2021 09:12:51 +0200 (CEST)
On Wed, 11 Aug 2021, Dmitry Karpov via curl-library wrote:
Thanks for the feedback, this is very helpful!
> From a brief look at the document, it looks like Curl will provide only
> WebSocket frame level of communication, so the client will have to implement
> full message assembling itself.
If you by "assembling" mean concatenating multiple frames until the FIN frame,
then my thinking was yes, so that we wouldn't have to buffer up potentially a
large amount of data before passing it on.
How do other client implementations work and how do they handle the unlimited
message size? Should we just impose our own maximum size and have applications
raise it when needed?
> If my understanding is correct, then it seems like a good initial approach
> to me - it handles the most critical WS steps: WS handshake, frame
> sending/receiving and error reporting, even though it leaves WS message
> layer communication (sending/receiving full message) to the clients.
That's my current thinking, yes.
I want the API to be "good enough" to get sufficiently advanced websockets
communication going against "most" server-side websockets implementations.
When we think it is, we can start working on code to make it real and then see
how it actually works with some early test client applications. The feature
will be marked EXPERIMENTAL until we deem it ready anyway so there will be
wiggle room to change things around all the way through until we decide it is
fine enough to carve in stone (and ship enabled by default in a release).
> As it was mentioned in some of our WS-related discussions, the WS message
> layer is more complex than the framing layer
Can you elaborate on this? Aren't ws messages just the payload from N frames
concatenated and delivered?
I know there can be control frames injected in the middle of stream of data
frames, but the only standard such frames are close, ping and pong and I
imagine libcurl would handle them and thus what is passed on to the client
would be an unbroken stream of data frames.
> libcurl should provide a way to the client to handle incoming message data.
> This means that besides Frame-based "send/receive" callbacks, as described
> in the document, there should be message-based callbacks on top of the
> Frame-layer, which would allow clients to work with WS messages, rather than
> with WS frames.
There's no way then for libcurl to avoid having to buffer the entire ws
message, right?
> A small note about iflags:
>
> " iflags is a bitmask featuring the following (incoming) flags:
> CURLWS_TEXT - this is text data
> CURLWS_BINARY - this is binary data
> CURLWS_FIN - this is also the final fragment of a message
> CURLWS_CLOSE - this transfer is now closed"
>
> The "Text" and "Binary" are special WS frame/message opcodes, so it is
> probably better to distinguish frame flags and the frame opcodes instead of
> mixing them together.
This has been mentioned before but I don't understand why.
Why does it matter to an application exactly how the information arrived? The
application doesn't see the websocket protocol and it doesn't have to know
much about it using this API.
> If client is supposed to handle WS frames it gets from libcurl, then it
> needs to know the precise opcode along with the frame flags, so it can
> properly handle cases when "control" and "data" frames from different
> messages are intermixed (i.e. one large "data" messages intermixed with many
> "control" messages) and when some "custom" opcodes are used for some
> proprietary WS communications.
To me, that sounds like an argument for providing all the opcodes through to
the application. I didn't understand that they are actually used like that,
especially not within the same message.
Can opcode 3-7 and b-f be used "at will" by implementations to signal
something without negotiating an extension?
-- / 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://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2021-08-12