Open kostasrim opened 2 years ago
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. Here's some further info about the issue.
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) :
target_link_libraries(udp_client "-sLLD_REPORT_UNDEFINED -sSOCKET_DEBUG=1 -sWEBSOCKET_DEBUG=1 -sERROR_ON_UNDEFINED_SYMBOLS=1 --shared-memory")
target_link_libraries(udp_client "-sPROXY_TO_PTHREAD")
target_link_libraries(udp_client "-sWASM=0")
target_link_libraries(udp_client "-sWEBSOCKET_URL=ws://localhost:7777/ -sWEBSOCKET_SUBPROTOCOL=binary")
Here is the output from websocket_to_posix_proxy when the test client is run:
websocket_to_posix_proxy server is now listening for WebSocket connections to ws://localhost:7777/
Established new proxy connection handler thread for incoming connection, at fd=4
Received: 47 45 54 20 2F 20 48 54 54 50 2F 31 2E 31 0D 0A 53 65 63 2D 57 65 62 53 6F 63 6B 65 74 2D 56 65 72 73 69 6F 6E 3A 20 31 33 0D 0A 53 65 63 2D 57 65 62 53 6F 63 6B 65 74 2D 4B 65 79 3A 20 6E 37 6C 34 59 38 63 77 78 6B 75 42 70 72 64 35 75 75 68 4A 6A 41 3D 3D 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 55 70 67 72 61 64 65 0D 0A 55 70 67 72 61 64 65 3A 20 77 65 62 73 6F 63 6B 65 74 0D 0A 53 65 63 2D 57 65 62 53 6F 63 6B 65 74 2D 45 78 74 65 6E 73 69 6F 6E 73 3A 20 70 65 72 6D 65 73 73 61 67 65 2D 64 65 66 6C 61 74 65 3B 20 63 6C 69 65 6E 74 5F 6D 61 78 5F 77 69 6E 64 6F 77 5F 62 69 74 73 0D 0A 48 6F 73 74 3A 20 6C 6F 63 61 6C 68 6F 73 74 3A 37 37 37 37 0D 0A 0D 0A
hashing key: "n7l4Y8cwxkuBprd5uuhJjA==258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
Sent handshake:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: mnjaTYnz87wIdX6AxxwYCIgvcjE=
Handshake received, entering message loop:
Received: 82 84 05 20 30 23 0B 20 30 23
Have 0+10==10 bytes now in queue
Received: FIN: 1, opcode: binary frame (0x2), mask: 0x23302005, payload length: 4 bytes, unmasked payload:
0E 00 00 00
Received too small sockets call message! size: 4 bytes, expected at least 8 bytes
Cleared used bytes, got 0 left in fragment queue.
Received: 82 8E 19 CA DC 00 69 A3 B2 67 6D A5 A8 68 7C BA B3 6E 7E CA
Have 0+20==20 bytes now in queue
Received: FIN: 1, opcode: binary frame (0x2), mask: 0x00DCCA19, payload length: 14 bytes, unmasked payload:
70 69 6E 67 74 6F 74 68 65 70 6F 6E 67 00
Unknown POSIX_SOCKET_MSG 1752461172 received!
Cleared used bytes, got 0 left in fragment queue.
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'd like to debug this further but I'm not sure, if that is the proper diagnosis of the issue or where to find the code that is doing that.
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?