Socket is still listening after/if Unity crashes

[iddqd]

Hello

I'm starting a TNet server inside a Unity Editor Extension. This works fine but in rare cases Unity crashes and the Sockets that I created are still running in the background although the host Process (Unity) has been closed.

If I restart Unity, the same port can no longer be used, because it's blocked by this ghost process. In TCPView i can see the following (see attachment). The PID's do not exist in Task Manager or Process Explorer and they cannot be killed inside TCPView. They are never removed or closed, only after a restart of windows.

I tried reusing the Socket with

1. mSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true )

This way I can reuse the port, but a new socket is created and the ghost processes still exist. If i try to connect from a client, it is not guaranteed to work since he might connect to the ghost process resulting in no connection.

Did you every encounter something like this? I was using TNet 1.6.6 and just upgraded to the lastest version but since it's hard to reproduce i cannot really tell if this is fixed, have you made any changes in this regards.

I would have thought that the Threads created by TNet (or any Unity Extension) are closed even if Unity crashes, but they are still running or at least the sockets are still listening.

I'm stuck on this issue and it breaks the functionality of my application, so any help is appreciated. I also understand that this might not be a TNet issue, but rather windows/mono/unity. Perhaps there's a workaround to gracefully handle this situation.

Thanks.

[ArenMook]

I'd say fix the reason for the crash, and don't waste any time trying to put a band-aid around this. TNet's thread may die, but without explicitly closing the socket, its state is unclear -- and if the application crashes, there is no way to explicitly call code causing it to close properly.

[iddqd]

Thanks for your quick reply.

Unfortunately there's nothing to fix in my code. It's pretty much only a TNet Server running.

I see two possible crash scenarios:
1) When closing Unity while the TNet Editor Extension is running.
2) Putting the PC into sleep and waking it back up while Unity+Tnet are running.

I saw in other threads that this could have been caused by UPnP and has been fixed in recent version. So I hope that was causing it.

[ArenMook]

TNet is all C#, which is managed, and C# will never crash Unity. Only C++ side can crash Unity (ie: using Unity's native functions somehow -- OnGUI comes to mind). The worst thing C# can do is lock up Unity with an endless loop.

[iddqd]

I did not know that. Thanks for the hints, i'll keep digging

[hippocoder]

We had this problem as well, basically - things can and will crash. They'll crash for reasons you have no control over. Antivirus might kick in when the game is running. Windows update. A skype message. Or an incoming call from a mobile phone. Lack of ram. Bad display driver. Computer overheats. Os messages. All sorts of things, the list of reasons why something will crash is pretty much endless, and often this is nothing to do with your code.

The only workaround in these situations is to host the server apart from the client. The concept of any client running a server is a nice one, and achievable but problems like this can and will happen. I can't think of any resolution for it really