Yes, with this asset you can remove the cost completely as long as you implement your own matchmaking to replace Unity's and accept that without the relays ~10% of connections will fail. We're not a big fan of failed connections, so by default the plugin falls back to using the relays if all other connection methods fail. This means that your players will always be able to connect, but you will have to pay Unity for any bandwidth used on the relays. If you don't want the relays to be used at all it is as simple as unchecking the "Connect Relay" option.
The relays do ensure that players can always connect, but most of the time they are not actually necessary.
Any host that is not behind a router can be connected to directly. No relays needed.
If the host is behind a router, then NAT punch-through can be used to connect.
This is successful ~90% of the time according to the best numbers we can find.*
Adding port forwarding on top of that increases the success rate a bit more.
If you allow for fallback to the relays then the success rate is 100% but you will have to pay Unity for the bandwidth
used by the ~10% of players that can only connect via relay.
If you don't allow for fallback to the relays then the success rate falls somewhere a bit short of 100%, but you never have to pay a dime.
*There aren't any hard numbers on this but every estimate we've found falls in this range (Peer-to-Peer Communication Across Network Address Translators, Behavior and Classification of NAT devices and implications for NAT Traversal)
Google or wikipedia can probably give you a decent technical answer, but you are here, so here is my quick and dirty version: When multiple computers are behind a router they all share a public IP address. When a client tries to connect to that shared IP the router needs some way to know which of the computers to actually connect to. Port forwarding is a way to tell the router to forward all traffic coming in on a specific port to a specific computer. There was a time when it was pretty common for users to have to do this manually from their router settings. Luckily those days are long gone and now we have automatic port forwarding, which is just what it sounds like. Instead of the user manually setting ports and ip addresses it is all handled automatically. The reason this isn't built into Unity already is that the relays don't need it. With relays everyone is connecting to Unity's server and no one is being connected to so port-forwarding is never an issue. Without the relays you need port-forwarding for players to be able to host a game behind a router and be connected to.
NAT Punch-through is...honestly pretty complicated, but here's the short version: Port forwarding doesn't work on all routers, or it may be disabled by users. NAT Punch-through is a more complicated way of accomplishing the same thing that port forwarding would normally be used for. It works by having every player connect to a third party server, known as a Facilitator. When a client tries to connect to a host, the Facilitator does some magic to find a set of ports that they can use to connect without the router blocking the connection. Once the client has connected to the host the Facilitator is taken completely out of the loop. No network traffic is sent through the Facilitator so it uses very little bandwidth / cpu. Pretty much the opposite of how the relays work.
Yes...except for when all other connection methods fail and clients are forced to connect via relay. If relay connections are disabled than all connections will be directly peer-to-peer.
The answer is almost definitely "yes."
The Facilitator is only used to establish the initial connection between client and host.
Once the connection is made all data passes directly from one peer to the other.
Nothing goes through the Facilitator so it uses very little bandwidth / cpu and will run on almost any hardware.
It has been tested and confirmed to work on AWS free tier and rackspace cloud hosting.
We also keep a Facilitator running at www.grabblesgame.com that you are welcome to use for testing / development.
There is no guarantee of up-time though and it could disappear at any moment so please don't try and use it in a released game.
Yes! We keep a Facilitator running at www.grabblesgame.com that you are welcome to use for testing / development. There is no guarantee of up-time though and it could disappear at any moment so please don't try and use it in a released game. You will need to find somewhere to host your own Facilitator before releasing your game.
Note: This is just one way to go about it. Any decently new OS should work to host the Facilitator. Some steps (like the dist-upgrade) may be avoided by using a newer version of linux.
Credit to Doghelmer for writing this up. Thanks!
sudo apt-get install libstdc++6
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
chmod u+x Facilitator
screen (starts the program)
"ctrl+a" and then "c" (creates a new window)
./Facilitator (starts the Facilitator)
"ctrl+a" and then "n" (switch to the previous window)
You need to edit the settings on your default Security Group:
There are many ways to accomplish this in linux depending on your preferences and distro. Here is one way that works in
Ubuntu and probably other Debian based distributions:
Credit to jiak1 for helping me figure this out. Thanks!
Facilitator.shchmod +x ./Facilitator.sh to give the script execute permissionsuntil /home/facilitator/Facilitator -v; do
echo "Facilitator crashed with exit code $?. Respawning.." >&2
sleep 1
done
This will run the Facilitator until it stops running, then print a message and run it again. Make sure to use the correct path to your Facilitator and to pass in any arguments you want. In this case I'm passing in -v to get verbose output but you could also pass in -p to set the port or -i to set the ip.
crontab -e to add a new entry to run the above script on reboot.@reboot screen -S Facilitator -d -m /home/facilitator/Facilitator.sh
screen you can use screen -r to see the running session and connect to it.
We will continue to support the plugin for as long as people are are still using it. If we stop supporting it I (Zebadiah Long) hereby do solemnly swear to release the source code. If UNET gets replaced with something else, or routers miraculously start working properly, or the sun implodes a few millenia early we will probably discontinue support.
No. I suspect it is possible, but there is no timeline on when I'll get around to figuring it out. Maybe never?
The library we use for puchthrough (RakNet) does not support WebSockets. So...that's a no. There are no plans to add WebSocket support at this time.
At it's heart matchmaking is really simple. You just need some way to store each host's connection data and some way for the clients to get the data so they can connect.
Steam lobbies are a popular choice but it's also fairly easy to roll your own system with something like php and mysql.
Here's an example with steam lobbies:
// Do this on the host in OnCreateMatch() after creating the steam lobby
SteamMatchmaking.SetLobbyData(steamIDLobby, "matchID", createMatchResponse.networkId);
SteamMatchmaking.SetLobbyData(steamIDLobby, "guid", natHelper.guid.ToString());
SteamMatchmaking.SetLobbyData(steamIDLobby, "publicIP", externalIP);
SteamMatchmaking.SetLobbyData(steamIDLobby, "internalIP", internalIP);
Clients can then find and join the steam lobby as normal. Once they are in a lobby they read the host's connection info from the lobby data and pass it in to StartClientAll() to connect.
I don't know man, I'm pretty sure you won't be using the relays on the consoles anyway so you probably don't need this plugin for a console only release. I'll update this if I ever figure out more.