-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
websocket, introduce blocking sends #14458
Conversation
When using `curl_ws_send()`, perform a blocking send of the data under the following conditions: - the websocket is in raw mode and the call is done from within a curl callback. A partial write of the data could subsequently mess up the ws framing, as a callback has a hard time handling this. - the websocket is encoding the data itself, has added it to its internal sendbuf. A partial flush of the buffer has unclear semantics for the caller, as they will have no idea what to send again. Fixes WebSockets tests with CURL_DBG_SOCK_WBLOCK=90 set.
Should this blocking behaviour be documented somewhere along with the other parts of curl that still blocking?
|
A good question. I did not really like to introduce this, but it seems necessary with the current design. Maybe @bagder has an idea how to address this. But if we go for this, it needs to be documented in |
There are a number of other blocking calls mentioned in TODO and KNOWN_BUGS. If
this is a temporary measure that might be fixed better in the future, then it
should probably go there, too.
|
Only perform blocking send when invoked by a callback.
Improved handling to make curl_ws_send() non-blocking in almost all cases when invoked outside a callback. Updated documentation. |
What is expected of clients who wish to resume a |
When using
curl_ws_send()
, perform a blocking send of the data if the call is done from within a curl callback. A partial write of the data could subsequently mess up the ws framing, as a callback has a hard time handling waits and repeated calls.Outside a callback,
curl_ws_send()
is always non-blocking except when generating a 0-length frame that could not completely be sent. This is no way to report this partial success.Document this behaviour in the function and add this as item to the TODO list. Also, add
ws
as protocol trace feature.Fixes WebSockets tests with CURL_DBG_SOCK_WBLOCK=90 set.