Hi Daniel,
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.
Summarizing this approach, it seems that libcurl will provide the following:
1. WS handshake handling over HTTP(s). This will include the "upgrade" and
handling WS handshake errors (like WS protocol requested by the client wasn't
selected by the server etc) and probably handling of some well-known WS
extensions like compression.
2. Basic WS framing capabilities - sending/receiving WS frames with all
necessary information (flags, data) needed for client to implement full message
assembling.
This should include compression/decompression, so the client will not have
to deal with this low-level stuff.
3. Proper WS closure implementation, so the client will have to specify only
close code and reason for client-initiated closures and get close code and
reason for server initiated closures (i.e. some WS info options or close
callback).
4. "WS alone" mode. Perform only basic WS handshake (probably with handling
compression extension), so the client will be able to handle send/receive raw
WS frames and do some custom processing.
5. Provide automatic Ping/Pong response and timer-based Ping/Pong pinging (with
optional client supplied Ping data).
6. Provide WS-specific error reporting - via proper WS error codes etc.
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.
As it was mentioned in some of our WS-related discussions, the WS message layer
is more complex than the framing layer, and potentially fully assembled WS
messages can be huge, so 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.
But this would require implementation of WS message layer in libcurl, which can
be done in some subsequent extensions of WS support in libcurl.
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.
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.
Thanks,
Dmitry Karpov
-----Original Message-----
From: curl-library <curl-library-boun...@cool.haxx.se> On Behalf Of Daniel
Stenberg via curl-library
Sent: Wednesday, August 11, 2021 2:41 PM
To: libcurl hacking <curl-library@cool.haxx.se>
Cc: Daniel Stenberg <dan...@haxx.se>
Subject: more WebSockets
Hi,
I've refreshed the wiki page a bit using input from the discussion so far. See
https://github.com/curl/curl/wiki/WebSockets
A few things I realized and tried to reflect in the page:
A single fragment can be 61 bits large and a message consists of multiple such
fragments: we must have an API that provides data piece by piece to the
applicaiton and signal the FIN when it arrives.
We need to provide a callback-based approach (as well) to allow for many
concurrent websocket transfers - especially for applications that want to mix
those up with a few "regular protocol" transfers as well. I've tried to
describe how it could work. Not sure it is flexible enough.
I added a few questions marked "TBD" in there that I don't think we have
answered yet.
I think we can design an API that can work. What's the biggest omissions or
mistakes in the current draft?
--
/ 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
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
