Cannot send Named Message to Client Prior to Disconnect
See original GitHub issueDescribe the bug In BossRoom, we sometimes need to just boot players (for example, if a different client joins with the same GUID). When we do this, we would first like to send an explanation message to the affected client. We attempted to do this like so:
MLAPI.Messaging.CustomMessagingManager.SendNamedMessage("ServerToClientSetDisconnectReason", clientId, buffer, NetworkChannel.Internal);
NetworkManager.Singleton.DisconnectClient(clientId);
However, this doesn’t work. The connection is severed immediately, and messages that are currently outstanding are not sent. Our expectation is that we’d be able to sequence these two events (sending a message and then disconnecting) without needing a coroutine workaround.
To Reproduce Steps to reproduce the behavior:
- In the BossRoom demo, go to ServerGameNetPortal.cs and replace
StartCoroutine(WaitToDisconnectClient)
with the contents ofWaitToDisconnectClient
(minus the WaitForSeconds call of course). - Build a non-develop version of the game, start host, and enter game.
- Start two clients and have them late join.
- Observe that the 2nd client boots the first, but that the message explaining WHY it is booted is lost. He should get an explicit message saying “You have logged in elsewhere using the same account”
Actual outcome Named Message sent just prior to disconnecting client is lost on disconnect.
Expected outcome All messages sent on a reliable channel prior to a disconnect should be delivered.
Screenshots If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):
- OS: e.g. Windows 10
- Unity Version: 2020.3.0f1
- MLAPI Version: 0.1.0
- MLAPI Commit: tag release/0.1.0
Additional context Add any other context about the problem here. Logs, code snippets would be useful here but please also consider attaching a minimal Unity project that reproduces the issue.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:8 (4 by maintainers)
Top GitHub Comments
Any progress with this one? I’m having the same issue as of today. I can implement some sort of workaround in my game, but still a dirty approach.
There are two changes relevant to this.
The first is the Connection Approval process can now be resolved asynchronously, giving you several frames to send messages. https://docs-multiplayer.unity3d.com/netcode/current/basics/connection-approval#networkmanagerconnectionapprovalresponse
The other is that the default transport (Unity Transport) now flushes the message send queue before sending a disconnect message, so you don’t have to manually “wait a bit” between your send and your disconnect.