So the one question that no one seems to ask around here is, can you have a separate Master Server written in something other than Unity? In theory it’s possible, you’re connecting to a remote (or local) IP, sending bytes here and there - who’s to say that Unity has to be on the other end of the connection!
I’ve been poking into result of the Network.Connect call to a separate UDP server (written in Java - it simply echos the bytes it receives to a console). It seems reasonable that if the pattern of the communication were demystified then you could write a third party connector that allows Unity developers to the use features built into Unity, rather than go through the crazyness of purchasing the various TCP/UDP add-on type solutions.
Feel free to tell me I’m crazy, but I’m just curious if anyone’s explored this option before.
you aren’t crazy but you are totally mixing stuff up as in if the master server was a problem or related to why you want to use the other solutions.
they offer stuff you can never do with unity networking, no matter how much you turn the tide, if you use an own master server or not has no impact on that, as the master server does nothing but listing the available games.
Well maybe ‘master server’ is the wrong name, but basically I want a separate non-unity server to manage things in the middle - I’d rather not have a Unity instance be the server in the middle to which everyone’s talking.
A long time Unity user named Zumwalt explored this idea to a great extent, only it was communication with a stock version of RakNet and not a custom server. He’s been begging the Unity folks to publish details on their application protocol, to no avail.
Search around for some of his threads.
Though, it would probably be far easier to use something like Lidgren from the get-go, instead of trying to reverse engineer Unity’s application protocol. Not that networking in Unity really gets much love, but you still can’t count on things not changing from release to release.
I’m in total agreement there and in fact we have a 3rd party application server that runs with .NET sockets - which seems to be the popular thing to do. But, whenever I use .NET sockets I always wondered to myself “why is everyone re-inventing the wheel” since Network.Connect is a Unity API.
Well there are a number of reasons you wouldn’t want to use use Unity’s custom RakNet implementation. Not only is the networking in Unity a black box in terms of it’s application protocol, you also are totally dependent on the Unitoids fixing whatever bugs exist.
That was a major issue in the 2.x cycle, when Unity’s networking…well didn’t quite work! Some of the more severe bugs were caused by mono threading issues, which meant it took like a year from the time the community figured them out until they were fixed in the next non-point update that included a mono update.
Yeah you can roll your own, but in my opinion a library like Lidgren offers the perfect level of abstraction to build your application protocol on top of without worrying about berkley sockets at the lowest level. The dev is also very responsive and you get the source to boot. No black boxes involved.
That Unity master server is just a database to store a list of currently running instances of your game, in which one of the players is still the host/server. I don’t think that’s what you’re looking for.
You could download the source code for the unity master server and run it. And in the code you can set the MasterServer.ipAddress to the server ip and the MasterServer.port to the port number. Then to test, cut the internet off and see if your client can see the host.
