Socket.io usage

[JMLX42]

Hi there,

we need to build some real-time networking for Minko (https://minko.io). We target HTML5, iOS, Android, Windows, Linux and macOS with a single C++11 source code. We need this networking thing to work on enterprise networks, so I'm thinking about using WebSocket for both the HTML5 and the native apps.

I like socket.io because it provides classic HTTP fallback.

I see emscripten has socket.io embedded in it: https://github.com/kripken/emscripten/blob/master/src/socket.io.js

I was thinking about creating a C++ wrapper that would wrap socket.io.js for the Emscripten implementation, and socket.io-client-cpp for the native implementation.

How is socket.io.js used inside emscripten? How can it be wrapped?

Regards,

[kripken]

We used socket.io in our webrtc code path (you can see where it is used in src/library.js). However, that isn't maintained, I'm afraid - testing was hard to do, and the work was never fully finished and stabilized.

It would be great to have a proper socket.io binding in emscripten. I wasn't aware they have a native one. Perhaps we could use the native one in both emscripten and native builds, and under the hood socket.io.js for emscripten?

One piece of code to look at is src/library_sockfs.js, that's our current networking layer (that should replace the parts still in src/library.js.

[JMLX42]

It would be great to have a proper socket.io binding in emscripten. I wasn't aware they have a native one. Perhaps we could use the native one in both emscripten and native builds, and under the hood socket.io.js for emscripten?

Maybe. But that native socket.io port already implement WebSockets. So Emscripten will emulate WebSocket to encapsulate WebSocket. Which won't work. Right?

[kripken]

I meant, if socket.io provides C or C++ code, then i assume that uses libc sockets under the hood. And then our libc socks in emscripten could be implemented by JS code from socket.io.

[JMLX42]

@kripken is there a flag to disable emscripten's socket => websocket framing? This way I could try the vanilla Socket.io C++ port directly and report back here to show the results.

[kripken]

I'm not sure. We used to have a flag to flip between websockets and webrtc, but not sure if we removed it when we stopped focusing on webrtc.

[JMLX42]

If I want to make a PR to add such define, where should I start looking?

[kripken]

I would start by reading the src/library_sockfs.js code, which implements websockets. If we can make that use socket.io directly that might make sense to do.

[JMLX42]

I think there are to different use cases here:

1. One has an existing UNIX socket C/C++ code base that one wants to port to HTML5: Emscripten WebSocket framing + websockify does the job out of the box.
2. One is creating a cross-platform C++ app and wants to add real-time networking.

I'm in the 2nd case. In this case, it makes sense to work with WebSockets even for the native builds because it should behave nicely on enterprise networks without configuration (opening ports). But if I use WebSocket in my native builds, then I have to make a special case for HTML5 builds to avoid Emscripten framing my WebSocket a second time. That's why a switch to disable WebSocket framing in Emscripten would be cool.

In my case, I also want to maximize compatibility. So instead of using WebSocket directly, I want to use Socket.io which wraps WebSockets but also provides automatic fallback to HTTP (long poll). I'm creating my networking server code from scratch too so there is no problem handling this fallback properly. But someone with an existing UNIX socket code (like in situation 1) won't have this fallback implemented. So Socket.io has no advantage in this case and raw WebSockets and current Emscripten implementation are fine.

To put it in a nushell:

• Emscripten automated WebSocket framing is fine as it is since it provides feature-wise compatibility on par with UNIX sockets out of the box.
• Using Socket.io instead of "raw" WebSocket framing inside Emscripten is pointless since all the features added by Socket.io are not supported by UNIX sockets.
• If one wants to use a custom native WebSocket implementation (such as the one of the Socket.io native port) because he wants more than what UNIX socket provides ; then he should be free to disable Emscripten's WebSocket framing.

That's why I think a switch to disable framing is needed, but the current Emscripten WebSockets framing should not use Socket.io.

I would start by reading the src/library_sockfs.js code.

Thanks. Will do.

Another solution is to see if the Socket.io native port can work with raw UNIX sockets without the WebSocket framing and let Emscripten do the job.

Edit: just posted an issue on the socket.io-client-cpp project https://github.com/socketio/socket.io-client-cpp/issues/113

[kripken]

I'm not sure what you mean by "a switch to disable WebSocket framing"?

[JMLX42]

I started with a x-platform WebSocket implementation:

https://github.com/aerys/minko/tree/dev/plugin/websocket

Using WebSocket++ on Windows, Linux, Android (tested and working, OSX and iOS should be pretty easy to add) and the Emscripten API for HTML5.

[stale[bot]]

This issue has been automatically marked as stale because there has been no activity in the past 2 years. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.