-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
recv()
not working even for tests/sockets/tcp_socket_echo_client.c
#15750
Comments
Most likely you have a found a real bug. It also looks like there are some gaps in the test coverage. If you would be interesting in help to fix these issues PRs would be most welcome. |
Hi Sam, thank you very much for confirming this/replying. As this is important for something I am working on I will take a look and update on this here. However, note that I am not that familiar with the codebase so I might ping for any questions :) Again your fast response is very much appreciated :) |
We are having exactly the same issue on both windows and mac, has there been any further info? Happy to contribute. |
We have been struggling to get some existing UDP client code to work in Emscripten. So, following some advice on another issue, I tried to follow the example in the tests. As pointed out above this particular test is broken. I built the websocket_to_posix_proxy program (MacOSX+Xcode 13.3)with the DEBUG #defines set. test_sockets_echo_client.c built was with Emscripten and TEST_DGRAM set with the following options (deduced from inspecting the test runner Python code) :
Here is the output from websocket_to_posix_proxy when the test client is run:
It took me a bit of trial and error to get this to work because the link options for the client that are used in the examples do not seem to be consistent with the documentation. It looks like the client is not encapsulating the proxied data properly for the proxy server. |
I have a small library written in C that uses POSIX TCP sockets which I compile to WASM via emscripten. I then call the exported WASM functions from JS in node to establish a connection to the TCP server proxied by websockify. However, this does not fully work. Even though it can connect and send data, the JS client never receives data from the server.
For this reason, I tried to play around with the test cases found in
tests/sockets/tcp_sockets_echo_client.c/
and I came up with this very minimal example (slightly simplified the boilerplate fromtcp_sockets_echo_client.c
).Which I compile via:
and run:
and a very simple TCP server written in python and proxied with websockify:
Now the issue is that after the client connects to the server and sends the data, the condition
if (FD_ISSET(server.fd, &fdr) && state == 1)
inmain_loop
is nevertrue
and as a consequence, we getShouldn't reach here, socket not readable
instdout
. Furthermore, on the server-side, the output hasdata sent
printed.I have also tried to run
python3 tests/runner.py sockets
to trigger the test cases for sockets that all pass. However, the printed output only refers to the servers reading/sending data to the clients, therefore making me question if the clients actually receive any data (there areasserts
in the test cases, but the output of the clients is not displayed by the runner.).Therefore, I wanted to test and see what the actual output of the client is when the tests are run. Instead of using the test runner, I compiled the
tcp_sockets_echo_client
with:and the
tcp_sockets_echo_server
with:Then I used
websockify
to proxy to the server and run the client with node:node out.js
and the output:Client:
Server:
Confirming my suspicion that the clients never receive any data (that is
if(!FD_ISSET(server.fd, &fdr))
) is true. Is this a bug withrecv
implementation or is there something else that I am missing?The text was updated successfully, but these errors were encountered: