.NET/C# Binding

[StinkySteak]

Hi, I want to create a WebTransport support for Unity, I've tried quiche, but it seems they dont have built-in for WT Yet. I've across this, and wanted to create the bindings for .NET first. Sadly I dont understand elixir so much, so it will take some time to learn too. Also, My env is windows.

My questions are:

• do I need the quinn or the WebTransport native files?
• Can you explain me, what are the things I need to do (in high level)

[BiagioFesta]

Hi! Thanks for your interest in adding WebTransport support for Unity and exploring the project. I’m not a Windows or C# expert myself, so I don’t have detailed guidance on setting everything up in that environment. However, I can share some key insights and potential steps:

1. Creating Bindings: You might want to check out csbindgen, a Rust project that helps generate C# bindings from Rust code. You could use it to generate C# bindings for the wtransport library. However, note that you’ll need to compile the Rust code as a dynamic library (DLL) rather than a static Rust library. The Rust documentation on linkage has details on how to do this.

2. Async Runtime Challenge: One of the more complex parts of this integration will be dealing with async runtimes. The wtransport library requires an async Rust runtime, specifically tokio. Directly calling Rust async functions from C# through FFI won’t work out-of-the-box because there won’t be a tokio runtime available in the C# context, which will cause panics.

   To handle this, you’ll need to create an additional layer in your bindings. This layer should start a tokio runtime and coordinate with the C# async environment (like managing tasks and callbacks). This approach will require some understanding of both Rust async runtimes and C# async handling.

3. Next Steps: Given the complexities, I’d suggest starting by experimenting with calling a simple async Rust function (running on tokio) from C#. This will help you get familiar with bridging between Rust’s and C#'s async models. Once you have that foundation, you can gradually work towards integrating wtransport.

This is definitely a challenging task, but it’s achievable with some groundwork on async integration. Good luck, and feel free to reach out if you have further questions along the way!

[StinkySteak]

I still have questions, when I compile the webTransport as native library, will it automatically include quinn?

[BiagioFesta]

Yes, in general, when you compile wtransport it will bring quinn code inside for the QUIC stack implementation

[StinkySteak]

Ok got it, in addition there is this https://github.com/quinn-rs/quinn-ffi, what do you think?

[BiagioFesta]

I was not aware about that, but it is probably a good start point and try to achieve the same with wtransport

[wegylexy]

Check FlyByWirelss.WebTransport out. It is for server, but you may get some ideas on how to build a WebTransport client with System.Net.Quic in .NET 6.

[StinkySteak]

I will take a look at it, thanks, give me time

[StinkySteak]

Check FlyByWirelss.WebTransport out. It is for server, but you may get some ideas on how to build a WebTransport client with System.Net.Quic in .NET 6.

@wegylexy Unity doesn't support Latest .NET API right, how problematic if they are separate instance do you think?

[wegylexy]

@StinkySteak If it's a Windows desktop game, you could implement the WebTransport client in a separate background service and use named pipe(s) (e.g. 1 named pipe client per WT bi-directional stream with 1 named pipe server per WT session) between the local background service and the game. Then you wouldn't be limited to the Unity API.

[StinkySteak]

I only intend to use the WebTransport server in dedicated server (linux), then the client can connect through javascript

[wegylexy]

In this case, you don't have to use a Unity server, thus no need for .NET binding or get limited to .NET Standard 2.1 only. What do you really want to achieve, regardless of the technology behind the scenes?

[StinkySteak]

What we're limited is the Unity Mono API, where we don't have access to QUIC API. If the unity can execute a background process, I guess it can be fine, if the control is easy

[wegylexy]

the client can connect through javascript

If you use JavaScript, you don't use Mono API, just use JavaScript WebTransport in your web client.

[StinkySteak]

The issue I'm unable to solve, is the server (unity instance) need to have the ability of to accept a webTransport connection

[wegylexy]

I mean, if you want to take advantage of WebTransport or any custom networking, don't use Unity Multiplay Hosting.

[StinkySteak]

I'm getting a little lost here, I'm not talking about Unity Multiplay Hosting anywhere. Lets say we have a Unity multiplayer game, using mirror, and we want to utilize QUIC for webBrowser which is webTransport. However Unity is a mono and do not have an access to your API you developed for .NET 6.
The root issue is: Unity cannot take advantage for .NET 6 API, is it clear?