websocket_to_posix_proxy in a container

[tdallapiazza]

Hi, At first, let me explained a little bit what I'm doing.

I have a modbus TCP server running in the browser with the code compiled with the flags to use the websocket_to_posix_proxy as explained in this documentation.

I tried to build the websocket_to_posix_proxy directly in windows but can't get it to work with the windows socket API. So I build it in WSL and the whole is working perfectly. When i run my script in the browser, it registers through websocket with the proxy and when sending modbus tcp requests from a third software, the proxy succesfully transfer the requests through websocket to the browser etc...

Now for ease of deployment, I'm trying to build the proxy in a docker container with alpine linux as a base. I carefully expose the required ports (8090 for the websocket and 8502 for the modbus tcp socket) and register them so that traffic on that ports will be forwarded to the container.

The build seems to work ok and the connection through the websocket seems also to work as expected (the proxy running in the container reacts when I start the script in the browser and the websocket handshare seems successfull). But when I run modbus tcp requests, I get a "connection reset" error.

Did anybody successfully implemented the websocket_to_posix_proxy in a docker container?

Kindest regards,

       Thomas

[maceip]

at one point I think @ktock wired it up in https://github.com/ktock/container2wasm -- but has accelerated off into wasi / qemu tcg territory aiui. nevertheless, his repo showcases 3 killer techniques (although its crazy what we have to do to get packets out):

1) fetch proxy, zero dependencies +all the cors headaches 2) ws => tcp proxy outside browser, so tcp over wss 3) i forget

the work over @ https://github.com/oligamiq/browser_wasi_shim is quite impressive and complex -- all i want is a threadpool!

it's not looking good for in-browser wasm & posix sockets. firefox killed direct-socket proposal, and the posix proxy you're asking for here is ancient. the wasi folks are mostly server-side; where did the browser people go?

best of luck out there

🤝 RST resetting, not by choice

[maceip]

🧟🧟‍♀️—back with one last message!

i had to mention https://github.com/leaningtech/webvm

strange licensing setup but they have yet another slick networking 'bridge'. they adapted the tailscale wasm module which allows your wasms to have a private mesh / use an exit node of your choosing.

[sbc100]

it's not looking good for in-browser wasm & posix sockets. firefox killed direct-socket proposal, and the posix proxy you're asking for here is ancient.

The posix proxy used in emscripten is at least somewhat tested and maintained, despite being "ancient". It implements TCP and UDP over wss.

The issue in question here seems to be about routing between the browser and the linux proxy running inside a container. This seems like it must be some kind of networking configuration issue, and likely not an issue with emscripten's websocket_to_posix_proxy specifically but I could be wrong.