Author Topic: Coming from built-in Unity networking  (Read 6247 times)

Suvu

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 11
    • View Profile
Coming from built-in Unity networking
« on: February 18, 2013, 10:09:47 AM »
Hey guys,
I started my project using the built-in networking in Unity, I'm loving TNet so far but I've been having trouble getting my head around some the workflow/concepts.

Most logic in my game is authoritative, so for example when a player spawns :
  • Server checks that all conditions have been met (client has signaled that they want to spawn, respawn time has passed ... etc)
  • Server allocates a NetworkViewID (making it the owner) and sends an RPC to all (server and all clients) to spawn a player (with the parameters : PlayerID, networkViewID, initialPosition)
  • Server and Clients (on receiving the RPC) Instantiate the playerObject and assign it's NetworkViewID
  • Server can now communicate with that object on all clients.
Control is also applied authoritatively :
  • Client streams input to server, with timestamp (also applies input locally to reduce the appearance of latency, and corrects for prediction errors when server updates are received)
  • Server checks input is valid and applies it to the playerObject
  • Server sends updated position back to all clients
Questions I have about TNet :
  • Can you allocate unique TNObject id's at runtime? Or do they only allocate themselves through TNManager.Create()? Then how would you communicate on dynamically created objects?
  • On receiving an RFC, can you find out who sent it? (RPCs have an optional parameter : NetworkMessageInfo which contains which player sent it, network timestamp etc)
  • Is there an equivalent to Network.time? (a time value that is synchronised on all clients, used for timestamps etc)
  • For an authoritative setup, would you avoid using TNManager.Create? (Because then any client could create network objects)
I have a suspicion I'm looking at this is completely the wrong way and making it way to difficult for myself....

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: Coming from built-in Unity networking
« Reply #1 on: February 18, 2013, 04:56:24 PM »
1. TNObject IDs are allocated automatically. There is no need to worry about this. TNObject.isMine tells you if you're the one who created this object.

2. Why do you need to know who sent the RFC? If you need this info, send TNManager.playerID as a parameter to your RFC function.

3. No, there is no built-innetwork time. If you've worked with Unity's networking then you likely already know that network time is very unreliable and can differ greatly across clients (I've seen it differ by over a second in some cases). You can send an RFC call from the hosting player to a newly connected player (in OnNetworkPlayerJoin) with the host's time, if you like.

4. There is no need to avoid TNManager.Create. Have your game code check TNManager.isHosting, and if so, then create (if you actually need only the authoritative host to be able to create).

dkoontz

  • Guest
Re: Coming from built-in Unity networking
« Reply #2 on: March 04, 2013, 07:35:48 PM »
2. Why do you need to know who sent the RFC? If you need this info, send TNManager.playerID as a parameter to your RFC function.

I can think of a few reasons related to authoritative server setups where you would want to know the source of an RFC.  For example, in converting one project from uLink to TNet I've run into this problem.  Previously what I was doing was having each player send the state of its controller input to the server several times per second.  The server saved this input using the id of the sender.  The various scripts on the server would then check this input if the player was for example occupying a vehicle.  However, if the client passes its own id as part of the RFC, then it could impersonate another client's input.  By the server not asking for the id, but basing it on the Player's id, there can be no spoofing via the RPC's params.

4. There is no need to avoid TNManager.Create. Have your game code check TNManager.isHosting, and if so, then create (if you actually need only the authoritative host to be able to create).

Would this mean that a malicious client could instantiate objects that would then be accepted by the other clients?  In a related vein, is there a way to stop a client from being able to send to a Target.All?  I know that command goes through the server, but in an authoritative server mode you would want to have the client communicate to the server, and then have the server send to All.  So if a non-host client tries sending to Target.All is it ignored, is it an error, does it go through to all clients?  Basically I'm looking for a mode or setting where only the Host can call TNManager.Create and clients can only use the RFC Target.Host, and only the server can send RFC's to something that's not Host.

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: Coming from built-in Unity networking
« Reply #3 on: March 04, 2013, 09:19:02 PM »
You really can't prevent someone from spoofing such trivial things as player IDs. Doing any kind of anti-hacking prevention measures in the library would be quite pointless as anyone with access to the library can then reverse engineer your game's traffic. If you worry about security in your game, write some basic fast encryption logic for the data that you send, and/or write custom packets to handle such traffic.

And as I always say, make a game that's worth hacking, then worry about hacking. 99% of the times any kind of anti-hacking measures are completely pointless.

dkoontz

  • Guest
Re: Coming from built-in Unity networking
« Reply #4 on: March 04, 2013, 11:49:39 PM »
You really can't prevent someone from spoofing such trivial things as player IDs. Doing any kind of anti-hacking prevention measures in the library would be quite pointless as anyone with access to the library can then reverse engineer your game's traffic.

Are you saying that the server has no way to identify any given client except through the information the client itself sends, similar to how a cookie is used to maintain a session when communicating with a web server?

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: Coming from built-in Unity networking
« Reply #5 on: March 05, 2013, 12:25:36 PM »
No, I am saying if you need this stuff, then you need to add new packets to the server to handle this kind of stuff in your own, private manner so that no one else knows how you did it. The source code is available for you to modify after all. ;)

enzi

  • Newbie
  • *
  • Thank You
  • -Given: 1
  • -Receive: 0
  • Posts: 21
    • View Profile
Re: Coming from built-in Unity networking
« Reply #6 on: March 05, 2013, 01:03:47 PM »
Quote
And as I always say, make a game that's worth hacking, then worry about hacking.

Excellent quote. I'll remember this. :)

But on topic. The server knows from which client it came through the IP address. That's pretty spoof free, isn't it?

Also if things should get more secure I'll add a simple system that sends an ID or string generated on the server to a client, so only the client and no one else knows about it. This ID/string is requested with every packet (guess this is overkill) or on a random timed (0.5-2sec) AUTH_CHALLENGE packet. If the client fails to send this, packets will be ignored.

With TCP I shouldn't have a problem with this. Kind of the OAUTH system that facebook uses only very stripped down.