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.html
