Network.Instantiate confusion (#2)

Basically this: http://forum.unity3d.com/threads/network-instantiate-confusion.118563/

I was looking for a way to check client input to the server before processing it (RPC/Instantiate) but did not find anything. This was discussed in the thread linked above, but a suitable solution was never given.

So clients can basically spam the server with prefabs and you can't do anything about it? If not, how do you prevent it?

 

Bump. Does anybody have suggestions?

 

You can put the Instantiate call in an RPC and have the server/master client make the call to each client. That's just one of a million ways to do it. If you need to check for permissions to execute a method, the fundamentals are the same in all cases.
1. Inform the master what you want to do, and possibly include the client's state
2. Process the request on the server and return a bool for permission
3. If true, execute method, otherwise handle the issue accordingly.

 

Thanks for your reply, of course I know that "soft" authorization could be done this way (but should't because it's unsafe, stuff could happen between sending "OK" and receiving the instantiated object from the client which creation might not be OK anymore).

But I'm worried that if someone recompiles the scripts, his client can just skip the authentification and create an object anyway. The server itself needs to check if the action the client is currently trying to perform is allowed for him. Is there a function that always gets called when a new object is instantiated (not only when the prefab has a script attached)?

That would obviously only be a problem if there were actually so many players that hacking would matter. But trusting the client with no option to turn it off seems like bad design to me.

It seems that the default network library of Unity has this fundamental security flaw with no way to fix it. A bool like Network.authoritativeServer = true; would be useful (that forbids clients to create objects, if they try anyway the server does not actually create them and they get kicked).

 

RIght, in my example above you'd want to manually register the ID on the server. Sure a player could recompile and make its own player object, but you can check if the ID matches what's been manually registered on the server and if not, poof! That's the first solution that comes to mind. I haven't tested that myself yet, but that's the first approach I'd go for. Seems the simplest.

EDIT: To attempt to answer your callback/event question... I am not sure that there's an OnInstantiation() method, if that's what you mean. I believe there's a framework out there (maybe it's playmaker? Eh...) that implements these. I've dug around the photon source quite a bit and it wouldn't be hard to add your own server side event when a new viewID is registered. Again, I have no experience doing this exact thing, but this would be my approach. Good luck!

 

Ok, thank you

We will probably implement our own netcode in our project. Not just because of this, but also because Unitys NetworkViews are not very useful for us. So far I haven't really found a good way to tell the client which map to load when he joins mid-game, without breaking the game for other clients.

 

Oh right. I use Photon and I easily forget Unity has networking too... Bah. Most of what I said was about Photon. I know nothing of Unity networking, haha

 

before doing your own network code, take a look at http://developer.muchdifferent.com
Inside uLink manual you can see how you can handle authoritative servers. You just set your servers as authoritative and then no instantiate is allowed on any clients. Only servers can instantiate objects. Scripts for clients and servers can be different. You can check the RPC's sender for other actions to see if it's from a valid source and if the operation is valid or not.

There is a lot more in the unity park sutie, you have server to server communication and you can hand over a player from one server to another with all required data to create zoned MMOs. To load maps you can simply send buffered RPCs and the RPCs can be delayed in terms of execution time when a client connects. Just let me know if you are interested to describe more.

There are many things which you don't have to code yourself if you go with unityPark sutie.
Relaible/unreliable RPCs
secure/ unsecure RPCs (you can select security per RPC)
custom class serialization with variable int and other optimized and compressed serialization mechanisms.
authoritative servers
automatic server instance creation
lobby system
zoned MMO creation capabilities
Lots of utility scripts (some of them are open source on github some others in our packages)

and a lot more

 

We have indeed already considered using uLink, but discovered that it's not free and we don't want to pay for stuff we could also code ourselves.

Also, we only wish to create "small" multiplayer or Coop, because the game also has a singleplayer part, so MMO stuff is unimportant for us.

I've done a lot of netcoding in the past, recreating all that functionality shouldn't be too difficult, just time-consuming. I love knowing exactly how code I use works, so I can be sure that it works as intented.

It's only a hobby project me and some people are doing, so don't worry about us not finishing it in time because we have to code stuff that already exists. Coding is fun

Still, thanks for your explanation, maybe someone else will find this useful in the future too.

 

Yup if you are doing it for fun, don't decrease the fun of it by not coding networking lib. Indeed it's challenging and fun and when you are not worry on time why not code it. If the process of development is as important as the final product, why not increase the value of dev process by gaining more experience in this networking thing