MacOS support

[gafferongames]

It's essential!

[hach-que]

Agreed. Everything today should actually work, it's just the installation aspect that we need to support for MacOS.

The way to theoretically make MacOS work today (prior to getting an installer for the helper done for it) would be:

• Install Mono
• Put the helper somewhere on disk
• Write a wrapper script that basically does mono helperexecutable.exe
• Add the manifest file to the correct location as per https://developer.chrome.com/extensions/nativeMessaging#native-messaging-host-location

[gafferongames]

Would it be possible to support it without requiring C#/Mono? Installing mono just for this seems a bit heavyweight.

[gafferongames]

Maybe somebody could whip up something quickly in Objective C or Swift, it's basically at the same level as C# on MacOS, and would run without adding significant dependencies.

[hach-que]

Yeah, I'm happy for the helper to be moved to C or Go. I went with C# initially because it was the fastest way to get the implementation of the helper done (it needs to deserialize JSON messages from stdin and serialize JSON messages to stdout, and that was just a little tricky to get done in C in a short timeframe).

[hach-que]

(Go kind of feels like the best solution here, especially if we can get libsodium statically linked into the helper so that it's just a single executable with no external dependencies at all)

[gafferongames]

Yeah. I love go!

[mreinstein]

any progress on this? I would absolutely love to move away from webrtc to netcode but this isn't tenable with windows as the only supported platform.

[hach-que]

I haven't done any further work on this as I haven't had time.

If you want to port the helper to Go and submit PRs, I'm more than happy to merge that work into this repository.

[mreinstein]

What do you folks think about web assembly as an alternative way to implement this helper cross-platform? emscripten might be able to take the netcode.io codebase and make it runnable on all supported node platforms. If it worked, besides macos it would make this possible on linux as a nice side effect.

[hach-que]

Web Assembly doesn't help because the APIs needed for netcode.io to work simply don't exist on the web. You can't open UDP sockets in a browser, so this extension uses a native helper to do the actual netcode.io work.

[mreinstein]

right, I get that udp isn't available. what I mean is rather than having a native binary for netcode + a c#/go bridge, It might make sense to write the bridge in c, and just compile the whole thing to webasm. That would be runnable via linux/win/mac and any other platforms node supports. So it wouldn't remove the need for a bridge, but it would reduce the complexity of it and bring it to more platforms.

[hach-que]

I don't think adding emscripten into the mix is going to make things less complex. It would probably make things slow (especially given that would also convert libsodium which has to do the crypto work). In addition, we'd be pulling in a runtime dependency on Node.js, instead of having just a single executable file. On Windows/Mac that makes the download much bigger, and on Linux it means dealing with package managers.

I think it's far easier if we use cgo to build a Go app that statically links against netcode.io. Both Go and the netcode.io C code are already portable, and Go produces single, statically linked executables for the target platforms.

On Tue, 13 Feb 2018, 10:54 AM Mike Reinstein notifications@github.com wrote:

right, I get that udp isn't available. what I mean is rather than having a native binary for netcode + a c#/go bridge, It might make sense to write the bridge in c, and just compile the whole thing to webasm. That would be runnable via linux/win/mac and any other platforms node supports. So it wouldn't remove the need for a bridge, but it would reduce the complexity of it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/RedpointGames/netcode.io-browser/issues/2#issuecomment-365103826, or mute the thread https://github.com/notifications/unsubscribe-auth/AAez-gLfoCn3GuVFn285n_ISc5UTA4SZks5tUM8sgaJpZM4OnhWu .

[mreinstein]

@hach-que @gafferongames so if this is ported to go, do we pull in libsodium, or do we directly use the netcode.io go port (https://github.com/wirepair/netcode)? I don't have enough experience in go and c# to do this myself but I'm thinking about creating a lucrative bounty to have this work done and I want to make sure I have the details right.

[hach-que]

I think it makes the most sense to just use the Go port that already exists. We want to keep any actual netcode.io implementation out of the helper, and really just use it access API calls that we can't access directly from JavaScript.

As far as I am aware, the Go port is up-to-date and maintained, but @gafferongames probably has a better idea around that. We'd also need to make sure the Go port works on all 3 platforms: Windows, macOS and Linux, but I'm kind of assuming it does since it doesn't seem to have any external dependencies.

[mreinstein]

the go port seems like the most elegant way to include it, I just wasn't sure about it's state of quality (I'm not suggesting it's low quality, more a question of if the port has been validated to work reasonably well or not.) So without offending anyone, is it fair to say that the go port is of high enough quality to be used at this point?

thanks!

[hach-que]

I'll defer that to @gafferongames who has a better idea on the state of the various ports.

[mreinstein]

Alright well let me know. I've got a few candidates that I think can do this so I'm happy/eager to push progress forward on this thing! :)

[gafferongames]

I recommend using the golang port, because it is excellent :)

• Glenn

On Feb 27, 2018, at 2:03 PM, Mike Reinstein notifications@github.com wrote:

@hach-que @gafferongames so if this is ported to go, do we pull in libsodium, or do we directly use the netcode.io go port? I don't have enough experience in go and c# to do this myself but I'm thinking about creating a lucrative bounty to have this work done and I want to make sure I have the details right.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[gafferongames]

Yes it’s pure go it’ll work everywhere

• Glenn

On Feb 27, 2018, at 2:51 PM, June Rhodes notifications@github.com wrote:

I think it makes the most sense to just use the Go port that already exists. We want to keep any actual netcode.io implementation out of the helper, and really just use it access API calls that we can't access directly from JavaScript.

As far as I am aware, the Go port is up-to-date and maintained, but @gafferongames probably has a better idea around that. We'd also need to make sure the Go port works on all 3 platforms: Windows, macOS and Linux, but I'm kind of assuming it does since it doesn't seem to have any external dependencies.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[gafferongames]

Yes!

• Glenn

On Feb 27, 2018, at 2:55 PM, Mike Reinstein notifications@github.com wrote:

the go port seems like the most elegant way to include it, I just wasn't sure about it's state of quality (I'm not suggesting it's low quality, more a question of if the port has been validated to work reasonably well or not.) So without offending anyone, is it fair to say that the go port is of high enough quality to be used at this point?

thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[mreinstein]

Some good news, there's a version of netcode.io.host/ ported to golang, and seems to run on my mac. Thanks to @falconandy for doing this work!

[mreinstein]

I've got this working locally, after porting netcode.io.demoserver and netcode.io.host !

here's the repo: https://github.com/mreinstein/netcode.io-browser-golang

Here's what it looks like running on my machine:

[hach-que]

@mreinstein I see you've edited your comment, but with regards to the current C# implementation that's used on Windows, I think it'd be better if we also replaced that with the Go implementation. The Go implementation is a single binary and doesn't have dependencies on either platform (unlike the C# implementation used for Windows which still relies on the .NET framework being installed).

[hach-que]

Also you've got the installer code included in the host which is great news - as it means I can simplify/remove the Windows-specific installer code here as well.

I think we can probably improve the installation process on the netcode.io browser extension site, by having the page automatically refresh an iframe after the host helper download starts. That way, we don't need to show an "installing" prompt; once the user runs the helper for the first time, the auto-refreshed iframe should start to see the helper become available and we can just show the installation flow entirely on the website itself.

[mreinstein]

@hach-que

I see you've edited your comment

Yes, I hope this wasn't too confusing. I funded the development of this work and was relaying details on behalf of the contractor that did the port, and the comment had incorrect information. I edited in the hopes that the comments would be cleaner and more understandable. (I managed to get netcode v1.0.1 working locally after that initial comment.)

with regards to the current C# implementation that's used on Windows, I think it'd be better if we also replaced that with the Go implementation.

I believe that the new golang based netcode.io.demoserver and netcode.io.host folders should work on windows, linux, and mac. I've only tested this on windows and mac though.

Also you've got the installer code included in the host which is great news - as it means I can simplify/remove the Windows-specific installer code here as well.

yeah! I think just about the only thing missing from my repository is the the browser extension related stuff.

Let me know if there's anything else I can do to help! I'm happy to do any sort of cleanup, docs, or front end changes that might be useful.

[hach-que]

I think the next step is to send through a PR, deleting the old host and wininstall folders. I'll keep the demo server as C# for now and update it to use the managed implementation of netcode.io (which does support protocol v1.01).

Once the PR is sent through, I'll try to find some time this weekend to make all the necessary changes to the build scripts + build servers in order to get it building for all platforms.

[mreinstein]

I think the next step is to send through a PR, deleting the old host and wininstall folders.

Okay, I'll send that along shortly.

I'll keep the demo server as C# for now and update it to use the managed implementation of netcode.io

Is this a temporary or permanent decision? Why not just use the go-based netcode.io.demoserver too ? It should be a drop-in replacment, and completely removes the need for .net on the demo machine/backend.

[mreinstein]

I'll try to find some time this weekend to make all the necessary changes to the build scripts + build servers

Assuming go is installed on the target platform, the specific build instructions are very simple, and documented here https://github.com/mreinstein/netcode.io-browser/tree/master/netcode.io.host

Build instructions for the go based netcode.io-demoserver are identical.

[mreinstein]

@hach-que have you had a chance to look at the PR? I've only submitted the netcode.io.host sub-project related changes for now.

[hach-que]

Sorry, this slipped my radar. Having a look now.

[hach-que]

@gafferongames @mreinstein I've released the binaries for macOS and Linux (as well as the new Go version for Windows) on the releases page. I've also updated https://netcode.redpoint.games/ so the basic test there is working again.

Can you confirm that everything is working on macOS / Linux? Thanks.

[mreinstein]

@hach-que works for me on mac!

What's the plan re: netcode.io.demoserver moving to go? Shall I send a PR with that change now?

[hach-que]

No, I'm going to keep the demo server as C# for the foreseeable future.

I have some changes planned for the website, including:

• Moving the client side code to TypeScript/Webpack
• Actually adding some game demos from Unity / UE

So I want to keep the website in a framework that I can understand / update.

[hach-que]

Depending on where things go, the demo server might end up being like 95% static website, and in that case would likely move onto Google Cloud Storage.

Then the only dynamic part would be netcode.io token issuance, which we can just do through HiveMP anyway.

[mreinstein]

I want to keep the website in a framework that I can understand / update. Then the only dynamic part would be netcode.io token issuance

I can certainly understand wanting to keep the backend server in a language you're more comfortable with. The only downside to the current approach is having to pull in 2 different netcode.io ports. The go demoserver code makes it possible to re-use more code.

the only dynamic part would be netcode.io token issuance, which we can just do through HiveMP anyway.

It might just be that I misunderstand the intent of netcode.io-browser: I'm under the impression this repo is meant to be a standalone demo that shows how to get udp transport into the browser. Deploying this repo will have you up and running without any external dependencies. It sounds like the plan instead is to move to a commercial, paid service?

[hach-que]

The intent of this repo is to be the browser extension supporting netcode.io.

The presence of a demo server in this repo isn't meant to be used as an example for how to do things in production; for one, the demo server does both token issuance and runs the game server, which isn't how you should actually do things. On the whole, it's a poor example.

When it was originally written, there wasn't really any better alternatives - all deployments of netcode.io required users to write and deploy their own authentication servers, so we also had to do the same here.

However, that's no longer the case. We provide a service through HiveMP to do netcode.io token issuance. For us, we're already paying for the HiveMP servers; there's no point in us also paying for servers to run netcode.redpoint.games when all those servers are doing is duplicating functionality we already have.

This doesn't impact any other netcode.io users or deployments - you can still do token auth on your own servers. All it does is reduce the costs of running the demo site.

[gafferongames]

For what it's worth, I'm totally OK with two separate netcode.io implementations being used in the demo. It checks for compatibility! :D

On Wed, Mar 21, 2018 at 2:52 PM, June Rhodes notifications@github.com wrote:

The intent of this repo is to be the browser extension supporting netcode.io.

The presence of a demo server in this repo isn't meant to be used as an example for how to do things in production; for one, the demo server does both token issuance and runs the game server, which isn't how you should actually do things. On the whole, it's a poor example.

When it was originally written, there wasn't really any better alternatives - all deployments of netcode.io required users to write and deploy their own authentication servers, so we also had to do the same here.

However, that's no longer the case. We provide a service through HiveMP to do netcode.io token issuance. For us, we're already paying for the HiveMP servers; there's no point in us also paying for servers to run netcode.redpoint.games when all those servers are doing is duplicating functionality we're already paying for.

This doesn't impact any other netcode.io users or deployments - you can still do token auth on your own servers. All it does is reduce the costs of running the demo site.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RedpointGames/netcode.io-browser/issues/2#issuecomment-375108333, or mute the thread https://github.com/notifications/unsubscribe-auth/AAqhUF1UMhY8dNSxHe4ox8qLiaQzgywIks5tgsu1gaJpZM4OnhWu .

[mreinstein]

This repo is the only example I've found of working, end-to-end netcode.io setup. So I might just be lamenting the added complexity of having both .net and go as a requirement to run it.

Perhaps the best thing would be to come up with a full example specifically for learning usage (basically expanding what I started here: https://gist.github.com/mreinstein/0284fbab6955c246d54224db5f402a24)

ideally something absolutely bare bones (1 language, minimal/no frontend build tooling, diagrams)