Skip to content

fix: ClientRpcs ignores NetworkObject's observer list [MTT-2878] #1836

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 22 commits into from
Mar 29, 2022

Conversation

NoelStephensUnity
Copy link
Collaborator

@NoelStephensUnity NoelStephensUnity commented Mar 25, 2022

This fixes the issue where NetworkBehaviour.__endSendClientRpc ignored the associated NetworkObject's Observers list and would send to all connected clients (including non-observers which would not have that NetworkObject instance).

Changelog

  • Fixed: ClientRpcs would always send to all connected clients by default as opposed to only sending to the NetworkObject's Observers list by default.

Testing and Documentation

  • Includes an integration test.

First pass fix for bug MTT-2878 where ClientRPCs do not take into account the NetworkObject's observers list
Adding observer checks when using ClientRpcParams.Send.TargetClientIds or ClientRpcParams.Send.TargetClientIdsNativeArray to let users know that they are sending a ClientRpc to a client that is not an observer of the NetworkObject.
This test verifies that only client observers of a NetworkObject receive the ClientRpc message.
Created GenerateObserverErrorMessage for generating the "sending to a non-observer" error message.
updated the test to check for the "sending to a non-observer" error message
Added check to see if only the host was supposed to receive the rpc when it was the only observer and check to see if the host received the rpc when no clients were connected.
updated comments and assert message.
NoelStephensUnity and others added 3 commits March 25, 2022 15:15
Removing the [MethodImpl(MethodImplOptions.AggressiveInlining)] attribute.
removing namespace.
Copy link
Contributor

@TwoTenPvP TwoTenPvP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor changes, overall looks neat!

TwoTenPvP and others added 4 commits March 28, 2022 16:21
addressing Albin's catches on how we log an error as well as assuring the array is disposed.
Setting the log level required to LogLevel.Error
Greater than or equal to Error...that is.  >.<
Copy link
Contributor

@TwoTenPvP TwoTenPvP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After the changes discussed here and in Slack. 👌🏻

@@ -158,7 +158,7 @@ internal void __endSendClientRpc(ref FastBufferWriter bufferWriter, uint rpcMeth
// We check to see if we need to shortcut for the case where we are the host/server and we can send a clientRPC
// to ourself. Sadly we have to figure that out from the list of clientIds :(
bool shouldSendToHost = false;

var logLevel = NetworkManager.LogLevel;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though I'm a big fan of temp variables for clarity, I'm not sure this actually does so here.

shouldSendToHost = true;
continue;
}
observerClientIds[observerCount++] = observerEnumerator.Current;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than go to the trouble of allocating and building up the client ids, why not simply here in the while loop do:

NetworkManager.SendMessage(ref clientRpcMessage, networkDelivery, observerEnumerator.Current)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After our internal discussion, I changed my approach to avoid the temporary memory allocation.

Removed var logLevel.
Re-organized the error logging check such that it will only perform the HashSet.Contains call when LogLevel.Error level or higher.
removing the allocation, avoiding cost of using NetworkManager.SendMessage, and now adding each observer client's message to the outbound queue one at a time.
@mattwalsh-unity mattwalsh-unity merged commit 3e9923c into develop Mar 29, 2022
@mattwalsh-unity mattwalsh-unity deleted the fix/mtt-2878-clientrpc-ignores-observers branch March 29, 2022 00:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants