Emscripten and networking?

I’ve noticed that Urho has pretty good Emscripten support and i was curious if anyone tested networking. Is it supported without any changes? Or it hasn’t been tested yet?

I’ve been looking into this topic.

AFAIK the libraries that urho uses for networking don’t compile with emscripten out of the box.

Emscripten provides libc networking (Brekeley socket API), which it uses JavaScript networking to emulate, which means only asynchronous operations should be used (kripken.github.io/emscripten-si … networking).
This is low level work, and I wouldn’t recommend it.

There’s a better approach. Emscripten lets you execute JS code directly, so you could use that to use JS networking directly which is so much simpler and elegant.
kripken.github.io/emscripten-si … javascript

AFAIK JS only has 2 networking systems: HTTP requests and websockets.
There are C++ libraries for both.
It should be possible to make a library that conditionally uses a JS or C++ implementation so there’ll be a single API for both regular and emscripten builds, similar to how Urho uses Direct3D/OpenGL.
It makes sense because if you’re using JS networking directly you’ll need HTTP/websocket servers, so you need to use the same networking system for the regular build.

There’s WebRTC and it’s also P2P. Checking the changelog, I’m not sure about the status of this feature, but I think they already fixed it with v1.34.

[quote]v1.34.2: 7/14/2015

  • Upgrade to new SIMD.js polyfill version and improved SIMD support.
  • Improved WebGL support in --proxy-to-worker mode (#3569)
  • Removed warning on unimplemented JS library functions
  • Fix WebGL 2 support with closure compiler
    - Fixed an issue with WebRTC support (#3574)
  • Fixed emcc to return a correct error process exit code when invoked with no input files
  • Fixed a compiler problem where global data might not get aligned correctly for SIMD.
  • Fixed a LLVM backend problem which caused recursive stack behavior when linking large codebases, which was seen to cause a stack overflow crash on Windows.
  • Full list of changes:

webrtc.github.io/samples/

Check also with BananaBread project (Cube2 port)
github.com/kripken/bananabread

BananaBread used to have WebRTC support, but that has been broken for a long time. There’s a PR with fixes, but apparently, it’s heaavily outdated and wasn’t merged by the authors: github.com/kripken/BananaBread/pull/38

The way they used to do networking was by relaying websocket connections: github.com/kripken/BananaBread/ … /server.py

Very crappy. :frowning:

There are a couple of paragraphs about some people’s experience porting Networking code here if anyone’s interested:
https://hacks.mozilla.org/2013/12/monster-madness-creating-games-on-the-web-with-emscripten/

[quote=“xalinou”]BananaBread used to have WebRTC support, but that has been broken for a long time. There’s a PR with fixes, but apparently, it’s heaavily outdated and wasn’t merged by the authors: github.com/kripken/BananaBread/pull/38

The way they used to do networking was by relaying websocket connections: github.com/kripken/BananaBread/ … /server.py

Very crappy. :frowning:[/quote]

You can check luser’s activity and fork branch here ‘webrtc-sockets’. I think he got this working again at some point and the possible support again…

github.com/luser/emscripten/com … tc-sockets
github.com/kripken/emscripten/i … -184876966