Authoritative server; anti-cheating; and protected content

[krissebesta]

Hi Aren, I have a few questions on TNet.  I'm looking at purchasing TNet but I have a few conflicting ideas regarding it's use.  I'm building a game that:

• I don't want anyone to be able to cheat and send false packets from the "server", which is why I am leaning towards an authoritative server where all game logic and memory variables are "untouchable" by clients.
• I have sets of content (DLC) that I will be allowing players to purchase, however, I do not want any clients talking directly to the DLC/content server.  I am planning on having each client log into the authoritative server first, then it will determine if local content should be enabled and downloaded DLC (if need be). 

Is there a way to create an actual authoritative server with TNet (without having client code in it; and vice-versa)?  I will have a lot of game logic and "rules" embedded in the auth server.  While the client app will mainly be interface code and talking to the server.  I don't want the clients to be able to cheat in any way.  Note this is not a FPS or other high traffic type game, more of a casual game.

Any suggestions or feedback is greatly appreciated.
Thanks,
Kris

[enzi]

Hey!

Yes this is possible, I use it for my project. I'm running the TNGameServer in a parallel thread to Unity. The GameServer is able to communicate with thread safe singletons but you want to minimize this as much as you can.

You are pretty much safe from "hacker packets" but that also depends how you're calculating things on your server. I'm only using keypress packets and simulate the world on the server. It's tricky at first to get it right but when you got it it's very solid approach imo. I tried several other techniques and was really unhappy with the results, especially sending only the delta keypresses. (User pressed Forward and calculate from there on till the user released Forward) It's too error prone for just a little saved bandwidth.

The cool thing about this is that you have a lot of control what happens and when. The server is never reliant on the simulation and vice versa. Also you'll dip in threading problems a lot if you don't have proper classes and not implement the BeginSend/EndSend workaround that I used in another thread.

I don't know how your coding skills are. If they are not that high I'd recommend using the normal GameClient code for the server and strip away the unnecessary stuff.

[krissebesta]

@enzi Thanks for the reply.  I'm interested to read more about the TNGameServer.  Do you have a link to more on it?  I don't know what you're talking about simulating keystrokes but it is something I do not want to have to resort to.  I'm also interested in your threading issues you seem to have a workaround for.  What do you mean you are running a TNGameServer "in a parallel thread" to Unity?  Can you please post a link and elaborate?

My coding skills are above average.  I've been a programmer for about 25 years (started with C and Delphi).

Thanks,
Kris

[ArenMook]

TNet.GameServer comes with TNet. I think he's referring to this thread: http://www.tasharen.com/forum/index.php?topic=2964.0

[krissebesta]

@enzi - Hey, why are you running a separate thread for your TNGameServer?  What is the need?

"I'm running the TNGameServer in a parallel thread to Unity. The GameServer is able to communicate with thread safe singletons but you want to minimize this as much as you can."

Thanks,
Kris

[enzi]

Hey!

Yes, I'm using the standard package. Running it is actually quite simple. Make a ServerStart.cs script, create a GameServer object, set parameters and Start it. I also added a public ServerStart property to GameServer.cs so I can communicate easier through a dispatcher.

Keeping the two threads safe isn't really problematic either. What you need is a proper thread safe generic array and not to many calls from thread to thread. I abstracted everything to a UserCommand class that has the info of user keystrokes and/or states. (rotation for example)

But keep in mind that you probably won't need this if you're running a 16-32 player server. I try getting 50-100 players into a lobby so optimizing and having the least amount of bottlenecks is crucial. The least thing you want is not receiving packets just because something stalls in the unity thread. And thanks to the garbage collector these things can happen.

[codestrikken]

I'm looking to do the same thing. I need a fully authoritative server. Not sure about enzi's approach if it would work for me, it's a good approach but I would rather recompile a server and have my code in it.
I have a silly question, how would a client send a packet to the server? all the "Send" options are for other clients. Would need a separate listener for it?

Thanks

[krissebesta]

@enzi - Thanks for more detail.  I'm going to stick with a simpler design (not having a separate thread for each Unity and TNet).  I need an authoritative style server that allows hundreds of players to meet, chat, and start games.  Games (channels) themselves will probably realistically max out at 10 players.  I'm building a casual style game that is basically turn based.  I have purchased TNet tonight and am just getting familiar with the documentation and will be busy implementing the code changes into my two projects (I've got a separate "server" and "client" project and a "common" folder for shared code).  All game logic and "rules" will be implemented on the server and the clients will only handle player interaction and interface.  The BIGGEST reason I decided to use TNet is because Unity's networking seems to only allow 32 "groups" which is similar to a channel, which is a HUGE show stopper for my auth server as I need to handle hundreds of games (channels/groups) all running at once.

Cheers! - Kris