Server Itself become Authoritative Host

[frostzerox]

After reviewing other posts I see that the first player to join is the host and is authoritative on all persistent objects based per channel. Then if they leave another player becomes host/authoritative over remaining persistent objects. But I would like to modify the actual standalone TNET Server to become directly authoritative over some objects so no player or even the host player can modify them.

Where in the server code would it best be to implement or bypass this default functionality for certain objects? So nobody can change them and the dedicated server can only update and change these objects. This is my first step in making the server itself be authoritative over certain game objects per game.

Eventually I would like to not only have the server control certain objects, but run AI as well. I am trying to get away from a player actually controlling or running the game. Seems like the host player can hack anything if he knows he is the host...

Also I don't like the idea of always having to run an initial Unity instance by itself as the "host player" since that would require PRO version to run headless optimally.

Any suggestions?

[ArenMook]

You can't do that because the server is not a player. That's like trying to make a garage own a car. A garage can't own a car. Only a person can own a car. Same with TNet and the "host" status.

That said, just because someone is "host" doesn't mean that you have to make them manage and own everything. A host flag is just a transparent thing that you may or may not use. If you don't want it, don't use it. But someone has to be responsible for objects, however. You'll need to pick a player.

[Masaaki]

I'd like to clarify what Aren says.
So basically, in TNet, the actual physical server application is nothing more than a middleman for routing messages (it's a bit more complicated than that, but it helps to think of it that way). That's pretty much all it does, and it has zero knowledge of Unity at all.
In my game, I needed a dedicated server model, and the way you do this in TNet is by having a special build of your game which acts as the "game server", by starting up a TNet server instance and immediately joining it. Therefore your "server" is technically a player (as far as TNet is concerned) and because it joins first, becomes the host. This is what I'm doing in my game (since I needed server authoritative logic) and works like a charm.

[chilly]

I'd like to clarify what Aren says.
So basically, in TNet, the actual physical server application is nothing more than a middleman for routing messages (it's a bit more complicated than that, but it helps to think of it that way). That's pretty much all it does, and it has zero knowledge of Unity at all.
In my game, I needed a dedicated server model, and the way you do this in TNet is by having a special build of your game which acts as the "game server", by starting up a TNet server instance and immediately joining it. Therefore your "server" is technically a player (as far as TNet is concerned) and because it joins first, becomes the host. This is what I'm doing in my game (since I needed server authoritative logic) and works like a charm.

I see your point, but...

isnt unity instance a single thread application?  meaning it can hold as much activity as a single core can handle?


so if you use 1 unity instance for dedicated host(to have authoritative server) in tnet.  woudnt that mean that you server may get very unresponsive and laggy with say over 50 online players in that particular unity instance?

which you may need to create another unity instance manually to hold another 50 players?


i am not sure yet, but sounds like unity networking cap is due of its single threaded capacity, so if more that 50 ccu in the instance the single core will get maxed out therefore gameplay ruined?

regarding ulink networking docs setup, they tried to to overcome this nasty cap of unity instance by doing a uZone witch will automatically fire up another unity server instance once it reaches certain number of ccu and assigns cpu affinity to the new fired up instance to avoid cpu saturation.

their philosophy sounds like :
if you have a multicore hardware for server, the assign affinity to a unity instance per core and have a master server that will check if one unity server instance is full the connect to the next in line

ie:
hardware with 8 cores, you can run 8 unity host (authoritative)  instances
max players per instance 50 (depending on your gameplay features, physics, server side collisions player checks etc...)
Like Aren said, if you use tnet in a unity instance fopr server side then your server resources will get eatup bu unity very quickly, therfore support less ccu.

= 8 x50 = 400 players in a 8 core hardware node.    sounds very little ccu for that hardware machine?  not sure.  but in theory that is it.

I think every networking tool that requires a unity instance to become a server will always have that cap due of the single threaded limitation.


would you care to explained on  how you overcoming this?  hopefully will help us to escalate the server setup.

thanks

[ArenMook]

TNet's server is a 50 kb stand-alone executable. It doesn't require Unity in order to run.

In fact, TNet's server solution compiles via C# or Mono, and does not use any of Unity's functionality -- and as such doesn't need it.

You can launch it from within Unity just by using TNServerInstance -- but this is just an option.

[chilly]

ohh, yeah,

i knew that it can run standalone without unity ,
but what i was referring to if used in unity instance to create an authority host as a (authoritative server)
then it will be capped at max ccu that unity can support in 1 single core hardware since it is a single threaded unity instance.

is this correct?

[ArenMook]

If you are going to bundle Unity's logic and its DLL into the stand-alone server, then yes, all bets are off at that point. You will be severely limiting yourself and not just because of resources, but because Unity is designed to run with only 1 game active at a time. So your game server will only handle 1 channel. That's it.

One of many reasons why I don't do it with TNet.