Disconnect Signal to Game

When you select "Disconnect" in MUSHclient, a disconnect signal gets sent to the game. I know because no matter how fast I log back in, it starts a new session. This is normal behavior.

I play on a laptop and mostly prefer to use Ethernet. If I switch to Wi-Fi by toggling the Windows network adapters, I notice that in an overwhelming majority of the time, a new session starts upon return. However, if there is a normal network outage (ISP, router problems, etc.), I can take over 10 minutes to reconnect and still be in the same session.

My assumption is that MUSHclient detects the changes to the network adapters and sends a disconnect signal to the game. Is there a way to prevent sending a disconnect signal to the game completely? For example, it would be cool if I could use the "Disconnect" button to temporarily leave the game and restart my computer and come back to the same session. Currently I have to resort to things like ending the MUSHclient process in Task Manager or rebooting my router to bypass the disconnect signal being sent.

Thanks for any possible suggestions!

This doesn't totally follow.

If you change network adapters there is no path for MUSHclient to send a "disconnect signal". It would be like trying to tell someone the phone has hung up after you got disconnected. Since you are disconnected you can't do that.

It is more likely that the game server hasn't noticed you disconnecting immediately (possibly because it didn't have anything to send you). That might explain why sometimes you can reconnect quickly and sometimes not.

But if the game is trying to tell you something (ie. sending packets over the network) and they get rejected due to the connection being dropped, then the game would probably terminate that session.

I do not know what Windows actually does but my guess is that it gracefully terminates connections when toggling the network adapters. Yanking an Ethernet cord or restarting a router is not so graceful so there is truly no path to send the signal.

But, in general, I assume there is no way to prevent the "disconnect signal" if I simply exit or restart MUSHclient? Thank you again!

I believe MUSHclient has nothing to do with this. It's just using a TCP socket provided by Windows.


There are many other ways this can happen that are not explicit disconnect signals, governed mostly by not resuming the TCP sequence and just generating a new random initial sequence number rather than by explicitly finalizing anything.


Huh? Chaos would ensue if anyone could send a disconnect signal for some other unrelated network adapter.


This would require bypassing the standard Windows socket interface to persist raw socket metadata to disk and then restore it later, which would be super abnormal network behavior that Windows does not want you to do.

If it is just a TCP socket provided by Windows as you said, it makes sense that toggling the network adapter gracefully terminates all activate TCP sockets first. Again, I am not sure if that is exactly what Windows does, but I think it is a valid theory.


I guess I was unclear. I do not mean the TCP socket's session; I mean the game's session. Like I said, I can consistently do this by unplugging my Ethernet cord or restarting my router before closing MUSHclient. If I return before the game realizes I am gone (Nick's example), I will return to the same session. I just disconnected for 11 minutes and 41 seconds via this method and returned without an issue. If I exit MUSHclient gracefully, it does not matter if I return within 5 seconds because the previous session was already terminated.

Why/how would the game session continue without continuing the underlying TCP session? If I were writing a server, I certainly would not let some random other TCP session resume an unaffiliated game session without forcing a new login. I think you'd need to persist the previous TCP metadata.

Anecdotally, I cannot get around logging my character in again to Aardwolf if I force kill my local program, regardless of what I do with my network, because the program is always going to generate a new TCP initial sequence number the next time I try to connect with it, and the server rightly does not recognize that new sequence as being a continuation of my previous session.


I don't think Windows does anything to the socket when you turn the network interface off. I do think it happens when the socket is closed because MUSHclient closes it or exits, but more importantly I also think it will not transfer a TCP session from one network interface to another network interface or across reboots. But I can easily turn my wifi off and then back on without being disconnected from the game. I just can't switch from wifi to wired without losing my connection because that's a different interface than before.

Sorry, I am still not explaining it clearly. Maybe I should not use the term session but "character state". When you are logged in, people can communicate and interact with you. If your network drops, they can still do that. When you log back in, you can see your chat history of when you disconnected (if Aardwolf has that functionality). Any other states your character was in persists. However, if you exit MUSHclient gracefully, your character is disconnected as if you quit. People cannot communicate with you. When you return, the state of your character is as if you quit and logged back in.

Anyhow, I was expecting this to be a shot in the dark. I appreciate the response!

Yeah, it's very likely that MUSHclient closing the socket on disconnect causes the system to then transmit the TCP session end signal, which probably then causes the server to quit your character.

Teeeeechnically, it might be possible to avoid calling Close on the socket here and only call ShutDown to put it into a non-communicative state without explicitly terminating: https://github.com/nickgammon/mushclient/blob/c93ddf9a97ddd401f854cba74140b847f684e640/Utilities.cpp#L1100-L1104

Unfortunately Microsoft says in https://learn.microsoft.com/en-us/cpp/mfc/reference/casyncsocket-class?view=msvc-170#remarks-34 that it's unsafe to do that, because they provide no guarantee that a socket can be safely reactivated afterward without creating a new one. Why that is, or under what circumstances, I have no idea.