MMO - Trying to get the hang of how an Auth server works.

Ok; at the moment I’m just working on the new user registration system and login system. At the moment I have a user login GUI script that adds and checks details from a mysql database. Currently it is the client checking if the user name already exists, and if no adding it etc. I was initially thinking about doing something similar with the player inventory etc, but then I realized that it would probably make the game easy to cheat at as I wasn’t using an Authoritative server.

I was therefore wondering how I could go about having the user name and password requested sent to the server, then the server checking the mysql database rather than the client.

I have looked at the networking demo and to be honest could use an example of how it would work in a simpler context such as passing user name and password info to the server etc.

Any help or examples of exactly how an authoritative server works in a simpler context than in the networking demo would be appreciated (so that I can “get my bearings” and then hopefully improve my understanding from there).

Thanks
Adam

I think that you are skipping several critical steps with regards to decisions about how the overall structure of your multiplayer should work.

It sounds like you are asking how to get a game server to handle roles that would traditionally be handled by other services – but probably only because you haven’t planned out how these other services are going to be designed and how they will have to interact. Authentication is certainly something that you can do in a Unity-based game server, but since probably aren’t going to be implementing an MMO without third-party or custom software on the back-end, and since things like authentication and inventory will most likely be handled by that, it probably isn’t something that you want to do.

I don’t suppose anyone could point me towards some documentation/ tutorials regarding how everything actually goes together. I mean at the moment I have a MySQL database and I have my client communicating with it; I assumed that it’d therefore be do-able using that.

I don’t want to come across as a noob (even though I am), but why do I need third-party software? What benefit will it be; why do I need to handle the inventory etc third-party when I would have thought I could just do it in unity and have it checking the database for things such as what items the player has etc; and just update it?

Again apologies if these are really simple/ stupid questions; as I said in a previous post I am a beginner and everyone has to start somewhere; I have 7 months to get up to speed enough with how everything will come together (I’m just hoping to learn as I go/ from my mistakes as I go).

Thanks

Let me approach this from an insurance / banking perspective (my life). What he is talking about is you have to have a service that handles the authentication and database communication per say.

The client should never do any of the authentication work, not for an MMO. Your client shows the fields aka username and password, then when you submit the information it just passes the information onto an authentication service on the server. The server has logic to handle the authentication and returns to the client a token which in turn is used to keep the client live with the server. All methods from that point forward utilize this token.

The security token is a required object to all methods as a variable. This variable is totally unique to the players. What happens is that when the client makes any sort of call back to the server for information it passes this token, the server methods then will deal with who the player is based on the token passed to it.

Now, in the beginning you need to determine what the client will handle and what the server will handle. How the client will make the request and how the server in turn will respond to the request.

One way to look at this, you drive up to an ATM, do you want the ATM to handle all of your security or do you want the server to handle it? The ATM requests your information, you supply it, the ATM passes this information back to the server then the server passes back the response to the client with regards to each request. All requests have a security token that is passed back to the server so the server knows who the individual is that is requesting the banking information.

MMO’s are pretty much the same concept. Let me know if any of this makes sense.

To add to zumwalts excellent post:

The token needs to be checked constantly on the backend, but the token itself is not enough!!!

You got to be real paranoid here. Dont trust the client code - never ever. That also means dont trust the network.

That means things like:

  • token has to be encrypted and unique for the client
  • token has a timeout value! When performing the server side check in the security service, also check if the presented token is still valid
  • refresh the timeout value if a correct client made a valid request
  • token itself is not enough - always use n-factor security. Someone could sniff the token in transit and resend it using his own requests, and thus steal the identity (worst case getting access to prepaid ingame currency = stealing money). This means that the token is one factor - and then you need other factors on top. Candidates are things like: IP address, username of user, another token - session token as an example etc. How many factors you need depends on how paranoid you are - but always more than 1
  • never ever send SQL directly from client to backend - always have a code layer packaged as a service. And remember to do input validation before processing, so you dont open up for SQL injection
  • silently ignore errors on security server - dont send information like “wrong password for given username” and other things that might help someone hack his way into the system. Return a simple boolean + token
  • protect your backend with firewalls. Preferably multiple firewalls

On the issue of multiple tech - its the good old “use the right tool for the right job”. Just because Unity can access a database, would you trust your bank to run its backend services using a game engine? I thought not. (Beware that I am not talking about your game server - I talk the back-office services your game needs). Game servers fit naturally into Unity. Code your back-office servers/services in a backend product like an application server or third party product that already took care of all the stuff I list above.

Etc.etc.

Hope that helps you along the way!

Yes this is kind of what I meant when I said

I was assuming therefore that I could have one unity project acting as a server, and one as a client; and then pass data between the two; what I’d like is a really simple example of how this is done (ie passing information from the client to server, and how to pass the result back); again if I’m being an idiot and this is not how it is done at all then let me know.

Also I dont suppose anyone who knows how this should all work could possibally PM me their msn as it would be nice to have it quickly explained if at all possible.

Thanks
Adam.

I googled a bit because this kind of interests me :smile:

I think this link could be of use to you:

Hell of a good find.
The article is written by some very knowledged individuals, it is a good read, take a look at that Hilm and then if you still have questions, let us know, we will do our best to further explain the architecture.

Ok if I’m seeing it correctally, I have the client; this updates the webserver with non important things such as if a window is broken; which then feeds into the game server and updated the clients. Then I have the client connecting to the game server, and then the game server updating the database?

In this case I guess the client would be my unity game, the webserver would be a bunch of php (or other) scripts running on a webserver; passing information to the game server?

Ok assuming all the above is correct (chances are it isn’t); I only have one confusion; exactally how is the game server created? I was initially assuming it would just be another unity project that could collect anything sent to it from the webserver/ clients; am I wrong in thinking this/ what are the alternatives?

PS; thanks everyone for your help/ patience, your all being a great help :smile:!

See the Figure3 in the earlier link. In that example, the web service is used for database connections. User management and persistence of data from game servers.

I would say (others may disagree), implement a server side application with C# on top of Mono. Because it is more familiar if you already use C# in Unity.

The server side will work as your backend and your unity application will be the client. There are multiplayer tutorials about how to do this from Unity.

Have fun! :wink:

:edit:
Here is one example ( I am sure you can google others as well)

And at this point I would like to point you to “my” 3rd party choice - SmartFoxServer - for at least consideration.

If you know hwo to code java, then its very easily extended, and I wrote a .NET client API for it

Other than that, I would either go with a J2EE’ish approach with servlets or webservices in e.g. Tomcat (Java again) or try your hand at C#. Dont think there are many scalable app server solutions in C# land yet (might be non-up to date on that).

This is where direction gets confusing. Are you making a thin client based MMO or a thick client based MMO? Depending on which direction you will be going will determine which route for the back end you will want to take.

Thin client :).

Concerning the “game server created with Unity”-approach: I’m doing it that way, and I in fact have only a single project for this. However, I’m using conditional compilation so that my server code doesn’t leak into the clients.

Edit: … in fact, there’s a lot more to it than server code not leaking into the clients, but I thought that was the most important to note … (end edit)

Usually, there’s two code paths in my approach:

a) For the client, which includes calls to the server, and receiving server messages

b) For the server, which includes sanity checks on what the clients are telling me, and the message distribution code. The server also handles the persistence by connecting directly to a database (MS SQL Server), but it’s designed in a way so that it would be comparatively easy to add a layer in between, if I find out that I need to (in fact, a few things are handled through a Webservice accessing another database … um, authentication :wink: ). And a lot of “technical stuff” that basically simply removes everything that’s not needed on a server - for obvious performance reasons: Simply no need for fancy-server side particle effects :wink:

As others have stated: Don’t even think about connecting directly to the database from the clients (unless everything runs in a secure, controlled environment, i.e. your own local network - but that would contradict the first M in MMO :wink: ).

With the approach “Unity project as game server”, which has some very nice advantages, you need to keep in mind, however, that this won’t scale very much, unless you come up with some solutions that are pretty complex to implement (I’m thinking of a RAKNET based intermediate layer that handles connecting multiple game servers with multiple clients - should be possible, but I haven’t followed that idea all the way through).

SmartFoxServer seems to be a pretty cool solution for many of the things you need aside from an actual “game server” (locations, physics, core game-logic that’s easiest to implement with Unity).

I am going to go with Thomas on this one. SmartfoxServer might actually be the way you want to go with this. You can get the Pro version with 20 licenses for free from their website and the documentation with examples of how networking works with regards to creating a MMO for example, is very good. This will give you documentation to use to learn from with regards to communication between the client and the server.

You have already stated you have a programming team together, so have them also take a look at the technology. Since you are creating a proof of concept game and not a production game, 20 connections is more than enough for a proof of concept. If this goes to production, 3k Euro is nothing compared to the income you will get from the end result.

SmartfoxServer is by default a headless server model and it is proven to handle tens of thousands of players with little effort for web based MMO’s.

Write your client in Unity, use the SmartfoxServer as the back end and you should be good to go. Of course you can still use Unity’s engine for the networking and game engine, it just depends on how much you want to do and which direction you want to ultimately take the game.

Hmm… Interesting stuff, I clearly did not think this through…

Of course you need to check and validate all physics and locations etc. coming from the clients, that much I realized. But using the same engine, both on client and server is clearly an advantage.

If using C#, would it not (in theory at least) be possible to use UnityEngine.dll on the server code as well…

UnityServer anyone? :slight_smile:

AFAIK, UnityEngine.dll is just a very thin wrapper around the actual engine core - so without the engine running as runtime environment, you’re probably out of luck.

I haven’t gone deeper into this, but I do get exceptions when I accidentally run test applications and forget to switch of logging via Debug.Log(…)

Makes sense.

So to sum things up, SmartFoxServer would probably be best for authentication and chat server, and jashan’s approach running a Unity instance as server probably best approach for building your GameServer.

It seems like pretty solid architecture for building a proof of concept for any kind of mmo game :slight_smile:

( Is now seriously wondering if he should start a hobby project… :roll: )

Ok… next to figure out how it’s actualy implemented lol… hopes theres a nice example of it all in the .net AIP SmartFoxServer Download.