Closed SoftwareGuy closed 1 month ago
I pointed out a some times ago, that in my game, when client disconnects, the server don't trigger the disconnections procress, and keep the connection for a little while, until he finally disconnect. This behavior seems to match what you wrote.
I pointed out a some times ago, that in my game, when client disconnects, the server don't trigger the disconnections procress, and keep the connection for a little while, until he finally disconnect. This behavior seems to match what you wrote.
This could be the same issue, which transport did you use?
This could be the same issue, which transport did you use?
Simple web transport
Note to vis: this is more a marker for me to discuss a potential rewrite of the transport's disconnection mechanism when I get back into full swing from my recent life event. Please leave open - I'll close later in the month.
The handling of client disconnection mechanism in Mirror could do with some TLC. There's some oddities where things like the ClientDisconnection function returns a boolean but the value is never used for some reason. In addition, with transports that don't disconnect clients on the same frame (ie. ENet, where it may send graceful disconnect messages to clients before they get the memo and gracefully disconnect), things like Mirror's "Disconnecting connection X for inactivity!" (https://github.com/SoftwareGuy/Ignorance/issues/76) messages are looped over and over until the connection finally drops off. It seems Mirror doesn't know that it just told a client to disconnect, and thus thinks it's still in a connected state when ideally it should be skipping the connection that's been told to disconnect that frame.
For those who want some backlog, see the
#ignorance-enet-and-friends
channel on the Discord where you'll see FakeByte and myself discussing some oddities with the disconnection part of the Transport layer.Once I've fully recovered over my concussion I will probably look into this, so let's keep this open as a convo starter.