Third Party Mirror Multi-Player Deployment Strategy

I'm new to Unity and developing a multi-player game with the following Use Case: A single Presenter has a VR Headset connected to a laptop and runs the game, they join as a client. Multiple Viewers use their web browser to navigate to a URL and join the game as clients. The Viewers will view the game as seen through the eyes of the Presenter, they have no interaction (at this stage).

My current approach is as follows: My Unity game uses Mirror for network communication. I have set the NetworkManager's Transport to Simple Web Transport (WebSockets). I performed a WebGL build and copied it to my web server and configured IIS to host this. I performed a Standalone Windows build and also copied it to my web server. I run the Windows build .exe file on my web server which will act as my server. Web browser clients connect to the WebGL build hosted in IIS.

Does this seem correct in principal please?

 

Is your game built with a dedicated server model? If so, how does your "Presenter" player authenticate and get authorized to be the one interacting with the game state inside of the dedicated server running on your windows box when the "Multiple Viewers" are only authorized for "view only"?

Most of the tutorials you will follow (for Mirror at least) seem to lean towards your "presenter" being the player and hosting the game server at the same time, removing the need for the dedicated server. *BUT* if you go that route, you have lots of challenges around the NAT networking between the viewer only clients trying to connect to the presenter's computer. If you know for certain that your presenter and all of the viewers will be on the same network, you don't need the dedicated server at all, and you can use the presenter as the host. For the record, I personally prefer the dedicated server route, but I'm a server guy by trade, so that's probably why.

Now, as for how to get the WEBGL build to your viewers, it is just a game client like any other game client. It just happens to run inside of the viewer's web browser. You can host it on a windows IIS server, or a linux nginx server, or really anywhere that can serve up html and static assets. How you get that client to people is not related at all to how they connect to the server (whether that be a dedicated server or the presenter's computer), so don't stress about them needing to be the same machine.

 

Thanks for your thoughts. To dip my toe in the water I created a simple game which I configured to use Simple Web Transport and it acted as both client and server. I hosted the web build in IIS for the browser clients to use and also ran a windows build .exe on the server and using the pre-built HUD set it to be the host. On my dev computer I ran the windows .exe as a client and it connected fine and a colleague of mine simultaneously navigated on his browser to the IIS hosted build and connected as a client. We could both independently see each other moving around. Result.

I now want to separate the client development from the server before we really start building upon this simple foundation. To begin with could I simply have a Client scene and a Server scene (keeping everything within the same Project for ease of source control management) and select the respective scene when performing the builds?

 

For your dedicated server -- you will probably want to run the game "Headless". There is a checkbox for making a headless / server build -- and you can then (from within your code) check to see if you are being run as a headless server and load the server code behavior at that point.

Check this thread for some other great pointers:
https://forum.unity.com/threads/eng...player-game-using-webgl.1003195/#post-6510606

And if you want to run your client and dedicated server all on the same machine, but to develop with it like it is a "real" server, I suggest trying it with Docker:
http://mcmahan.games/minimal-dedicated-server-tutorial.html

 

Hi. That's really interesting thanks. In your opinion do you feel there is much advantage in creating a separate project for the server. I like the separation of concerns and can see how the server could be much leaner on its own but having no Unity experience at all am concerned that assets and code cannot be shared and this could possibly be problematic. I am used to being able to simply create a new Visual Studio Project in the Solution and build/deploy that but I have no idea what Unity would make of that.

 

If this is your first multiplayer project in Unity, I suggest you keep them together for developer efficiency (and that is what I am doing). Long term, I *assumed* I would be refactoring all of my server code to run outside of the Unity runtime to get better performance out of it, but that was less important than just getting my game to a state where people can start playing it so that I could do a better job of designing a FUN experience first and foremost.

For the beginning, design your experience's mechanic around the realistic limitations of the technology (server, player devices, etc) and then as you learn how to optimize and get more out of the tech, you can design more and more complex experiences.

 

Seems sound advice. I'll try and organise and comment my code to help distinguish between client and server code. Thanks

 

I have been further developing my project and cannot seem to grasp the fundamental principal for multi-user WebGL client and host configuration. I have my Unity scene which is using Mirror (Simple Web Transport) and acting as client and server. I configured the Mirror Simple Web Transport to port 80.

Initially I built a Windows .exe and ran that locally and additionally ran another instance in the Unity Editor. Using the game's UI I selected Host + Client in one instance and Client (IP Address localhost) in the other. Websocket communication flowed fine.

I then built a WebGL version and uploaded it to our own webserver and published it in IIS. I also uploaded a Windows .exe version to the same webserver thinking that I would need to additionally run the Windows .exe build to act as the Host while the remote players would access the WebGL version from their browsers. When I launched the Windows .exe game it wouldn't allow me to connect as a Host. I then built a headless version and could see in the console window that I was getting a websocket error: "SocketException: An attempt was made to access a socket in a way forbidden by its access permissions." I think that this may because port 80 is being held by IIS. At the browser side of things, when I enter the IP address of the webserver and connect as a Client I get the following error: "WebSocket connection to 'ws://IP Address Here/' failed: Error during WebSocket handshake: Unexpected response code: 404".

I am now thinking I have completely misunderstood how it all works. I am now thinking that perhaps the WebGL build which I am publishing on IIS can act as the Host when the IIS website is started (eliminating the Windows .exe), I just need to change the code so it detects it is being hosted on the webserver automatically starts in Host mode. And as it is within IIS, which has authority over port 80, it can access the websocket traffic. If this causes the WebGL Host to work properly this may eliminate the client side error when trying to connect. It's a long shot!

This naïve reasoning is based only on how my ASP.Net Web API Controllers fire up and are listening for HTTP requests once they are published in IIS, I saw it as being similar.

Any comments, thoughts or guidance very welcome.

 

I had the following diagram which I used to define a similar workflow when building my headless server. Notice the BLUE steps that the developer has to do any time there is a change in the game code -- this is where all the builds have to be made and distributed.

I've added the webGL build flow for a Player's Web Browser client for your case with the 3 steps written in green. Note that the steps aren't visually in order, as STEP 1 is asking the server for the html index file, and it is that html which tells the player's web browser to download the webGL build, which then gets downloaded in STEP 2. After the build is downloaded, to the player's web browser runs that webGL build within the context of the browser and then finally in STEP 3, it connects to the Mirror server on port 7777.

Hopefully this helps a little. Let me know if anything in there doesn't work in your case though, as I've not done a webgl build connecting to a multiplayer headless, I'm just assuming it works like other web builds

 

Very helpful diagram and accompanying explanation, thanks. I created a WebGL build (Mirror Simple Web Transport, port 80) and published it on our webserver. I then created a Windows build (Mirror Simple Web Transport, port 80) and ran it on a new GoDaddy virtual server as a Host. This setup works well, I can run a Windows build and connect to the GoDaddy server Host and I can run the game in the browser from our webserver and connect to the GoDaddy server and player data is exchanged.

However, we are creating an enterprise solution for a very secure client and their web browsers will not be able to access the development GoDaddy server, only our very secure webserver. When I run the Windows build on the webserver it fails to start as a Host. It is very difficult to allow traffic through new ports on the secure webserver but currently I cannot establish websocket communication over port 80, possibly related to IIS using port 80 (just a guess).

Does it seem possible to both publish the WebGL build for HTTP access over port 80 AND run a .exe which is acting as a Host with websocket communication over port 80 on the same server?

 

I finally found a way to solve my problem. I hope this helps others who also want to run an application on their server but find it cannot listen on port 80/443 because port 80/443 has been reserved for IIS. I finally solved the problem as follows:
I created a new Domain and pointed it to my webserver. I then created a new Website in IIS bound to my new Domain. I pointed the Website to an empty folder. I then downloaded and installed Microsoft's URL Rewrite extension for IIS along with the Application Request Routing extension:

• URL Rewrite
• Application Request Routing

After these were installed I could select my new Website in IIS and in the IIS section to the right double-click the new URL Rewrite option. An Add Rule dialog appears and I could select a Reverse Proxy option and create a simple rule to re-direct traffic to localhost:80 and back again for outbound traffic. Incredibly, it worked!
I'm just a developer trying to wrestle a complex project towards delivery so this may have its flaws or you may know of a better solution, but for me I can now move on.

 

Your IIS server (and any other web server) is 100% going to "own" the port 80 traffic (and 443, if you have setup an SSL certificate and are running in secure mode).

What that means is that the moment that you start up your server, it will attempt to start the IIS "service", and that service will take over listening for all traffic to any ports, blocking your game server from being able to also listen on those ports.

If you are using the IIS to relay requests over to your locally running server (listening on some other port, I assume), then that will work, but I wouldn't recommend it from a performance standpoint. You are introducing an extra layer of load to your server and latency to your game's network stack, both of which will bite you when your product really starts to succeed.

As your client can't access a server on the web, but they will be able to access your server to download the webGL Client -- why you don't run IIS on 80/443 and just run your game server on another port?

If your client can't access anything else other than port 80/443 from their computers, then your other alternative is to create two network interfaces on the same machine -- this means that you will have two IP addresses and you can setup two dns records for something like web.yourproject.com and game.yourproject.com to point to those two IP addresses.

Once you have that setup, you will tell IIS to bind to the web.yourproject.com IP address, and tell your Mirror game service to bind to the game.yourproject.com address.

I updated my diagram to include the multiple network / IP address on it. In the diagram, I used 192.168.1.100 and 192.168.1.101, but your server will likely have different IP addresses for its network interfaces.

 

Thanks for all your advice on this topic, helped set me on a better path.