Request: Update project for handling web-assembly

[robindespouys]

Hello @hanseuljun,

First of all nice job for this wrapper!
I am using it now with standelone builds but I would like to be able to make webGL builds.
I forked you project in order to make it compatible with https://github.com/paullouisageneau/datachannel-wasm .
Sadly I could not make it work.
I would like to be able to use the same code base and build to webGL and standelone plateformes from unity.

If by any chance you have updated this project or have special setup on unity side let me now.

And if you know what should be updated on this wrapper but doesn't have time and/or energy I would be delighted to contribute :).

Thanks again for your work.

[hanseuljun]

Hi @robindespouys,

Thanks for an interesting suggestion for this project. But unfortunately, due to my lack of time and ability, I will have to only mention an issue that prevented me from WebGL support and what was my approach instead, as I also met this issue previously and am no longer using Unity for the project that made be create this Unity wrapper due to that.

If I am understanding correctly, Wasm's security model is based on the assumption that every .wasm file can come from a different developer. Given this, webassembly committee decided to not allow sharing buffers (e.g., byte arrays) between .wasm files. Thus, if you build your Unity project into a .wasm file and datachannel-wasm into another, they cannot exchange buffers (e.g., byte arrays) between each other, as that violates wasm's security policy.

While there technically are other Unity-based solutions for this situation, this experience scared me enough to port my Unity project into c++, as webassembly support is essential to my project and I felt like I would dodge a lot of issue later by doing that then, which seems quite true from my experience since then.

In case you believe in yourself and would like to stick to your Unity project, the way should be calling WebRTC functions included in browsers through a javascript Unity plugin. You will need to create this javascript plugin that exposes the WebRTC javascript functions into C#, and call them in C# from your existing project. To make your project support not only WebGL but Windows, it would be better for the C# function names exposed by the javascript plugin to match the function names of datachannel-unity, as datachannel-wasm does for libdatachannel. Be careful going this route as the development/debugging experience is going to be really bumpy.

Hope good luck with your work!

[paullouisageneau]

If I am understanding correctly, Wasm's security model is based on the assumption that every .wasm file can come from a different developer. Given this, webassembly committee decided to not allow sharing buffers (e.g., byte arrays) between .wasm files. Thus, if you build your Unity project into a .wasm file and datachannel-wasm into another, they cannot exchange buffers (e.g., byte arrays) between each other, as that violates wasm's security policy.

Just adding my grain of salt here. While this is true for an HTML page running different .wasm files, the consideration should be irrelevant here.

When you build modules for WebAssembly, you simply build static libraries (e.g. .lib or .a) like for other targets (e.g. x86 or ARM), only they contain wasm bytecode. Then, when the static libraries are linked together, the linker outputs a single .wasm file. Basically, .wasm file are like .exe files. The security model is also quite similar: in normal conditions, a process can't read the memory space of another process.

So, while I'm not sure about what Unity does under the hood, it must emit a single .wasm file with everything linked together in the end.

[hanseuljun]

@paullouisageneau You are right! Sorry about spreading wrong information. I met that issue (no buffer sharing) doing something else with another Unity plugin, which I cannot clearly recall which it was, and messed up in the above comment.