ServerRpc
#
IntroductionA ServerRpc
provides you with the ability to send information from a client to a server just like you would invoke a method from within a class. A ServerRpc
is a remote procedure call (RPC) that can be only invoked by a client and will always be received and executed on the server/host.
#
Declaring a ServerRpcYou can declare a ServerRpc
by:
- Creating a method that ends with the
ServerRpc
suffix within aNetworkBehaviour
derived class. - Adding the
[ServerRpc]
attribute above the method
#
Example of declaring a ServerRpc:The above example uses the default [ServerRpc] attribute settings which only allows a client owner (client that owns NetworkObject
associated with the NetworkBehaviour
containing the ServerRpc
method) invocation rights. Any client that isn't the owner won't be allowed to invoke the ServerRpc
.
#
ServerRpc Ownership And ServerRpcParamsThere are times where you might want any client to have ServerRpc
invocation rights. You can easily accomplish this by setting the ServerRpc
attribute's RequireOwnership
parameter to false like in the example below:
In the above example, you will also notice that MyGlobalServerRpc
takes a single parameter of type ServerRpcParams
. This parameter type is optional, but it can be useful to identify which client was requesting the server invoke the RPC. The ServerRpcParams.Receive.SenderClientId
property is automatically set upon the server receiving the ServerRpc
request and used to get the server-side NetworkClient
instance of the client (sender).
Best Practice
Using the ServerRpcParams.Receive.SenderClientId
property is considered the best practice to identify which client was invoking the ServerRpc
. It isn't recommended to send the client identifier via an additional ulong
parameter added to the ServerRpc
:
The primary reason, especially when RequireOwnership == false
, is that it can introduce potential security issues. The secondary reason is that this value is already automatically provided to you via ServerRpcParams
without the additional ulong
parameter bandwidth overhead you would incur by sending the client identifier as a ServerRpc
parameter.
Now, taking the best practices example into consideration, you might want to have other valid parameters added to your ServerRpc
. When adding additional parameters other than the ServerRpcParams
parameter, you must declare ServerRpcParams
as the last parameter of the ServerRpc
:
Looking at the above example, we can see the client invoking the PlayerShootGunServerRpc
method passes in a world position based on perhaps a screen space crosshair position to world space position, the ServerRpcParams
, and the ServerRpc
doesn't require ownership.
Alternate Owner Example
Of course, if your project's design was such that a weapon changes ownership when it's picked up by a player, then you would only allow owners to invoke the method and would only need the one Vector3
parameter like in the example below:
#
Invoking a ServerRpcFrom the example below that uses the PlayerOwnerShootGunServerRpc
method, you can see that you would invoke it just any other method:
#
ServerRpc TimingThe following are a few timing diagrams to help provide additional visual context when invoking a ServerRpc
.



warning
When running as a host, RPCs are invoked immediately within the same stack as the method invoking the RPC. Since a host is both considered a server and a client, you should avoid design patterns where a ClientRpc invokes a ServerRpc that invokes the same ClientRpc as this can end up in a stack overflow (that is, infinite recursion).
#
See Also- ClientRpc
- RPC Params
- See examples of how these were used in Boss Room.