Server & Client RPCs combined

[SpicedPigeon]

Is your feature request related to a problem? Please describe.
We want to call Client & Server Code with one RPC. The server should call the method directly and send an RPC to the client.
Currently this is not possible.

Describe the solution you'd like
Have a Method Attribute which is called "RPC" or "SharedRPC" which i can tag my methods with.
It then instead of only calling an Client RPC it also executes the function on the server.

Additional context
We have exposed functions which only foward their calls to an Unity Event. Our components now can listen to that event on the server and client. To do this i have to write something like this:

private void CalledSomewhereOnTheServer(){
      DoServerThings();
      onChangeUnityEvent?.Invoke(23);
      MyClientRpc(23);
}

[ClientRpc]
private void MyClientRpc(int i){
      onChangeUnityEvent?.Invoke(i);
}

[NoelStephensUnity]

@SpicedPigeon
Have you read through the ClientRpc Documentation where it discusses how to send a ClientRpc to a specific client (or clients)?

If you are running a host, then you need be aware that a host can send itself both ClientRpcs and ServerRpcs.

One way to exclude the host-client would be:

private void CalledSomewhereOnTheServer(){
      DoServerThings();
      onChangeUnityEvent?.Invoke(23);
        var clientRpcParams = new ClientRpcParams
        {
            Send = new ClientRpcSendParams
            {
                TargetClientIds = NetworkManager.ConnectedClientsIds.Where((c) => c != NetworkManager.ServerClientId).ToList()
            }
        };
      MyClientRpc(23, clientRpcParams);
}

[ClientRpc]
private void MyClientRpc(int i, ClientRpcParams clientRpcParams = default)){
      onChangeUnityEvent?.Invoke(i);
}

However, that does have some additional overhead and since you are invoking from the server invoked RPC (i.e. host-server) and since a host will directly invoke the RPC (i.e. not send the actual message) to avoid the additional overhead you can alternately do this:

[ClientRpc]
private void MyClientRpc(int i))
{
    if (IsHost) {return;}
    onChangeUnityEvent?.Invoke(i);
}

Let me know if this information helps resolve your issue?

[zachstronaut]

See also: #2615

[zachstronaut]

Code can get very verbose because RPCs are only-server and only-client currently. It would be extremely nice to have an RPC to can be called from either.

[NoelStephensUnity]

@zachstronaut
Have you tried using custom named messages?
They are relatively easy to implement and not client or server specific.

[zachstronaut]

@zachstronaut Have you tried using custom named messages? They are relatively easy to implement and not client or server specific.

Thanks Noel, yes indeed custom messages are the method I earmarked for implementing some of the features I'd like to see from RPCs in the future. I appreciate you making sure I was aware of this!

Still, something like this ticket's proposal (or #2615) would be a very useful builtin feature to save folks from re-implementing it themselves and also minimize some repetitive verbosity in code. Your main competing library has more flexible RPCs in this regard, and I definitely appreciated that when I was using their product.

[NoelStephensUnity]

@SpicedPigeon @zachstronaut
So...you are looking for something like a [BroadcastRpc]?
As a side note:
Read the above about custom named messages as this "broadcasts" to anyone listening for the named message.

Regarding a [BroadcastRpc]:
Since NGO is a client-server architecture, clients have no end point to other clients. This means that a [BroadcastRpc] would look like this when a client invokes it:

• (Client) Invoke [BroadcastRpc] (Client to Server)
• (Server) Receive [BroadcastRpc], forward [BroadcastRpc] to all other clients, process [BroadcastRpc]
• (Remaining Clients) Receive [BroadcastRpc] and process it

With a named message, it is pretty much the exact pattern:

• (Client) send named message (Client to Server)
• (Server) Receive named message, forward named message to all other clients, process named message
• (Remaining Clients) Receive and process named message

The only downside to a named message is that it does require some additional code, but that can be templatized and/or integrated into a derived NetworkBehaviour that allows you to register named messages for the instance.

I will pass this concept along to the team, but you might be better off running with a named message for broadcasting type scenarios.

[zachstronaut]

@NoelStephensUnity Sometimes you want to do this, especially in two player games and especially when you are trying to do more client authority to make a game's networking feel more modern and less laggy:

void Example()
{
    // m_sendToRemoteParams are ClientRpcParams that exclude a host client via TargetClientIds
    if (IsServer) NewInteraction_ClientRpc( _interactable, m_sendToRemoteParams );
    else NewInteraction_ServerRpc( _interactable );
}

[ServerRpc]
void NewInteraction_ServerRpc( NetworkBehaviourReference _interactable )
{
    NewInteraction( _interactable );
}

[ClientRpc]
void NewInteraction_ClientRpc( NetworkBehaviourReference _interactable, ClientRpcParams _clientRpcParams = default )
{
    NewInteraction( _interactable );
}

void NewInteraction( NetworkBehaviourReference _interactable )
{
    // shared code goes here
}

That's all very verbose. A more configurable[Rpc] with additional attribute arguments would let you do:

void Example()
{
    // m_sendToRemoteParams are RpcParams that exclude a host client via TargetClientIds
    NewInteraction_Rpc( _interactable, m_sendToRemoteParams );
}

[Rpc( allowExectionFrom = SomeNetcodeEnum.All )]
void NewInteractionRpc( NetworkBehaviourReference _interactable, RpcParams _rpcParams = default )
{
    // shared code goes here
}

Incidentally, my use case actually overlaps with #2465 too because I wouldn't need to deal with the TargetClientIds and RpcParams if you could configure an RPC via its attribute to not execute on the host.

[NoelStephensUnity]

@zachstronaut
Nice... thank you for the additional context.
Indeed it looks like what is desired is a [BroadcastRpc].
It would actually be better to have a completely different attribute for this to avoid introducing any bugs with the existing ServerRpc and ClientRpc flow and the ILPP side of things would be a bit different as well (a different type of table generated etc).

I will definitely make mention of this... but....since you can achieve the same thing using named messages it could be a hard sell. With named messages you can actually have "channels" defined by the server for like teams based broadcasts...
Something along the lines of this:

    public interface IListenChannelHandler
    {
        void ReceiveMessageHandler(ulong senderClientId, FastBufferReader messagePayload);
    }

    [ClientRpc]
    private void OnListenChannel(string channelName, NetworkBehaviourReference networkBehaviourReference, ClientRpcParams clientRpcParams = default)
    {
        if (networkBehaviourReference.TryGet(out NetworkBehaviour ListenChannelHandler))
        {
            var handler = ListenChannelHandler as IListenChannelHandler;
            NetworkManager.CustomMessagingManager.RegisterNamedMessageHandler(channelName, handler.ReceiveMessageHandler);
        }        
    }

    [ClientRpc]
    private void OnSquelchChannel(string channelName, ClientRpcParams clientRpcParams = default)
    {
        NetworkManager.CustomMessagingManager.UnregisterNamedMessageHandler(channelName);
    }

This allows you to control who is listening to what "channels" that are defined by a name (turned to hash when registered).
Then it is just a matter of pre-instantiating the handlers to be used (MonoBehaviour or NetworkBehaviour)... the above is just super-simple pseudo code... but I think it provides the general idea.