-
-
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
Cannot send message larger than 8192 bytes with websocket using unix socket on libcurl 8.10.0 and later, which previously worked #15865
Comments
So I think the actual issues are the following:
@icing Do you have any idea? |
Additional note: I tested this with Linux and Windows, and it worked without problem there. So only macOS has this issue? |
@na-trium-144 the difference on macOS is probably due to different internal buffers for unix domain sockets, meaning other OS would most likely block on larger sizes. As to the behaviour you see: You have then to call Does that help? |
@icing Thanks for comment! std::string msg(20000, 'a');
const char *begin = msg.c_str();
const char *current = begin;
const char *end = begin + msg.size();
int i = 0;
do {
std::size_t sent;
std::cout << std::endl;
std::cout << "calling curl_ws_send() #" << ++i
<< ": msg from " << current - begin << " to " << end - begin << std::endl;
ret = curl_ws_send(handle, current, end - current, &sent, 0, CURLWS_BINARY);
std::cout << "ret=" << ret << ", sent=" << sent << std::endl;
current += sent;
std::this_thread::sleep_for(std::chrono::seconds(1));
} while (ret == CURLE_AGAIN);
It looks working, |
- add DEBUG env var CURL_WS_CHUNK_EAGAIN to simulate blocking aftert a chunk of an encoded websocket frame has been sent. - update test_20_08 to simulate conditions in curl#15865
Oh, thanks for all the details. I simulated this in curl's test suite and indeed, the last byte was corrupted. Oh my. I fixed this in #15901 and hope this works for you as well. If you can build curl from that PR and verify the fix, that would be appreciated! |
I tried with that PR and it's working fine. Thanks! |
Are you sure about this? It is not documented and is out of character with how send/recv calls work. Why should the caller have to adjust buffer and buflen in the subsequent call? If a recv/send returns an EAGAIN then it would make sense to send the same buffer and length again. That is just how those calls work. As you know. I don't get it |
I agree that this is not how send/recv ususally works. I think someone needs to fix this. Update: I implemented sane behaviour for |
- add DEBUG env var CURL_WS_CHUNK_EAGAIN to simulate blocking aftert a chunk of an encoded websocket frame has been sent. - update test_20_08 to simulate conditions in curl#15865
@na-trium-144 In #15901 I now made This should not invalidate the changes you made, but you might want to test this again. |
Thanks |
I did this
Trying to send large message using websocket via unix socket.
Minimal reproducible example:
When I run this with libcurl 8.11.1, the trace output says it sent only 8192 bytes, while return value indicates that it sent 19999 bytes (seems to be always
message length - 1
) and error code is CURLE_AGAIN.(Meanwhile the server side seems to be receiving nothing.)
It seems message of 8192 bytes or less (8184 bytes or less in actual message) can be sent without problem.
I expected the following
With libcurl 8.8.0 it had always successfully sent 20000 bytes of message over unix socket.
Additionally, if I use normal tcp connection instead of unix socket (by just removing
CURLOPT_UNIX_SOCKET_PATH
line), I could send 20000 bytes of message with websocket even with libcurl 8.11.1.Is there any breaking change (or bug) about unix socket between 8.8.0 and 8.11.1?
curl/libcurl version
the not working version
the working version
operating system
MacOS Sonoma
uname -a
:The text was updated successfully, but these errors were encountered: