Author Topic: TNet Architecture (Authoritative Server, Semi-Authoritative, Server, PvP)  (Read 5868 times)

gg67

  • Jr. Member
  • **
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 66
    • View Profile
I'm a little confused on the different types of network architectures used today (Authoritative Server, Semi-Authoritative, Client-Authoritative, PvP) and when each should be used. I'm also curious as to how TNet can be used to create each. In another post I saw that the examples that come with TNet use the Client-Authoritative method, but that may not be the best solution in every case. Can anybody give a quick explanation of each, their pros/cons and how one could built using TNet?

Specific to me, I'm looking for the best network architecture that will work best for a persistent MMO style game. I wouldn't think Client-Auth would work well since that makes cheating very easy.

Thanks!

PS. I know it's a lot but I think a lot of people would benefit from this.
« Last Edit: January 22, 2014, 06:05:19 PM by gg67 »

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Stock TNet is always client-authoritative. You could add your own anti-cheating logic to the server, but the more you add to the server, the less clients it will be able to handle. Anti-cheating logic always differs with each type of the game, so it's best if you add exactly what you need.

In most cases you can get away with the other clients verifying all data coming to them. If you have 4 players in the channel, and one does something invalid and 3 others all go "wtf?", they can all send an RFC call to the channel's host saying that they've noticed an abnormality. The host can then boot the offending player. Likewise you could add this logic to the server itself if you're keen on modifying its code.

TNet was designed to be approachable and extensible, but for an MMO you may want to consider its scope. The bigger you go, the more demanding your server hardware will need to be, and the more optimized the code will have to be as well. Just keep in mind that the more you offload on your clients, the less you'll need to do, and the more you will be able to get away with in terms of server hardware, outgoing bandwidth, and resource utilization.

gg67

  • Jr. Member
  • **
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 66
    • View Profile
If I did want to go server authoritative (and didn't mind the huge amount of resources), how would I go about doing it with TNet? Also, out of curiosity, does TNet use any of Unity's networking solution? Or have you created everything from the ground up?

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
TNet doesn't use Unity's networking, which is why the server executable is only ~50 kb instead of 10 megabytes.

To add code to your server side, just modify the server code files (TNet\Server folder). You can test it from within Unity by creating an instance of it using TNServerInstance, or you can compile it into a stand-alone executable as I've done. The readme file contains info on where to find the Visual Studio solution files for the server.