Hi,
I’m currently using Unity as a web client in a multiplayer game and using another software as game server. To handle the network communication I use c# native sockets (System.Net.Socket) through mono in Unity.
I’m having some problems with Unity crashing on me quite often (it stops responding and is then shutdown by mac os). I’m not getting any output in the Unity Console when it crashes. Besides the crashing the network communication seems to work fine.
My question is if there is any known problem or restrictions using a Unity Web build in combination with mono socket implementation. Is this a valid way to use the Unity Web player?
//ohm
I’ve done the same sort of thing, so I know it’s possible.
It sounds like you’re having some kind of threading issue, actually, either because of bad synchronization or (more likely) because your socket is blocking. Unity itself is single-threaded, so any I/O operation that blocks (like reading or writing to a TCP stream, or even opening a connection) will hang up the whole application until it finishes.
Hi
I use .net/mono sockets in my Unity projects without any issues, but as Jormungandr says you can hang the whole game if you don’t thread it.
If I do this:
//SendAuthRequestToServer sends some data via UDP and waits for a response
_thread = new Thread(SendAuthRequestToServer);
_thread.Start();
it works great, BUT if I just call the method:
SendAuthRequestToServer();
The game hangs until a response is received - don’t think it crashes though - although I think the browser crashes on certain un-handled exceptions (not sure if this is ALL exceptions but if they are un-handled then it is bad anyway).
Ta
JT
Ok, I’m actually using async calls like BeginReceive and then callbacks to handle received tcp packages. I’m currently using just Connect and Send calls instead of BeginConnect and BeginSend. I’ll probably need to use the async versions of all socket functions and catch all exceptions. And the use of async callbacks will force me to make all received network data that MonoBehaviour::Update access thread safe.
Does this sound like a good approach?
That sounds like a good approach.
We had some bugs when using the async functions and running on Windows in an older version of Unity, but I believe that was fixed by 2.1; I mention it mostly as a reminder that you should test this stuff cross-platform if you intend it to run that way.
Good luck!
Did you ever find a fix to this?
I am having exactly the same issue. Using TcpClient async connect and recieve. On exit Unity player/unity editor/web player crashes hard every time.
I’ve now spend 2 days trying to find the bug - everything is handled in exceptions, I use dispose to clean up - still things crash for me.
Any help would be greatly appreciated 
Guys,
This is a known issue (for us at least!) and is to to do with how threads that get created to handle async socket operations are dealt with then Unity shuts down. Unfortunately we do not have a workaround other than to recommend using blocking socket calls in a new thread.
A typical bug report we see says that Firefox or IE on a PC crashes when the page is reloaded or the tab is closed.
We have done some work in Mono for Unity 3.0 to avoid this problem.
Kind regards,
Graham
Its also a known problem here in the community that any use of async callback can and will kill the webplayer on shutdown and with it the browser process (you will often also see a significantly raised unity editor crash probability as the editor behaves like the webplayer on game end …). for that reason, working with chrome during development can save quite some time, as only a tab will die when this happens not the whole browser
Thanks for the tip Dreamora!
@dendrophile
Can please specify what exactly it is you guys did to mono in unity 3 ?
Because i have a major problem with my network code running in Unity 3. I am using a c# client to connect to a red dwarf(aka darkstar) server. Internally it uses the TcpClient with asynch calls.
I was going nuts trying to find the error yesterday. The unity client just didn’t want to connect to the server. Then i thought about trying it in unity 2 because the code hasn’t changed. And there it worked.
But in unity 2 i still get the weird behaviour with unity crashing after several login/logouts or that it crashes unexpectedly after closing unity with cmd+q.
So i hoped that the problems would be gone in Unity 3. But there it doesn’t work at all. I don’t know if it is a Unity 3 bug , or if it has something to do with the sockets and the changes you did with mono maybe.
I am thinking about changing the internal socket code to blocking calls in a new thread in the future, but for now i just wanted to test the game code , and currently under Unity3 it doesn’t work at all.
The next step would be to debug it.
Do you guys have any idea what the problem could be ?
thx
Mike
You need to use a policy server in Unity 3 similar to Flash or Silverlight. There is a new security model around socket communications.
/Thomas
@Mike
The fix we made was deep down in the Mono thread handling code. I can’t be more specific because all I saw was a checkin of a zipped up copy of our version of mono. Note that this fix has not been incorporated into any beta release yet, so the version out in the fields will still have async thread related crashes, most typically triggered by socket code.
If you have code that works in 2.x but not 3.0beta the most likely cause is the socket policy feature that you can read about in the user manual for 3.0. You need to check that the remote server will accept socket requests before opening a socket.
Thanks,
Graham
Thanks for your answer Thomas.
But i thought that this concerns only the webplayer and not a standalone version , like it is written in the docs ? Or is affecting all sockets use ?
Because the webplayer build is not available in the beta right now and the Editor preferences mention when the active build is webplayer , then it simulates the security rule. Or does it simulate them all the time right now ?
And the same with iPhone/iPad. The next step after getting this to work i wanted to test the same project with the iPhone/iPad. Will i get the same problems there ?
Any help concerning this would great.
thanks
Mike
Wow , you guys are responding very quickly.
@Graham
thanks for you answer. Is it better then to change the socket code to blocking in a new thread even if there will be a possible fix to that problem in the future ?
And I hope i can get the darkstar server to accept socket requests before opening a socket. I have no clue yet on how to do that. I may need to post in their forums to find a solution.
Thanks
Mike
Hi Mike,
The mono fix will be included in the next release. I am not 100% sure on the exact timing, but we try to do releases every 10-14 days. (Just depends on what we are fixing and what gets reported.) For now try using blocking sockets in your own threads. This should help you workaround your problem for now.
Note, however, that Thomas and me are guessing really what your problem is. All we know is that you cannot connect to your server. We’ve jumped to conclusions around socket policy (but that should only affect webplayers) and this mono threading issue (but that is most commonly a problem closing a webplayer). Maybe try giving us some snippets from your log file?
Thanks,
Graham
What Graham says
Additionally - if you run beta 3, then upgrade to beta 4. In beta 3 there was a bug that more or less blocked all socket communication even when you had a policy server.
Just FYI
/Thomas
Thanks for your help Graham.
I was wondering myself the same thing because in the Docs it says it only affects the webplayer and the editor if the build settings are set to webplayer , which isn’t the case with my project.
In the meantime it seems i got it to work. Weird enough the only thing that i did (i think) was to set the scene in the build settings and build a standalone once.
I will continue debugging and testing it further.
Thank you for your help so far. And the hint with the new security features. I will to take that in to account when Unity 3 will be released and the web player becomes an option.
thanks again
Mike
Building a standalone changes the editor to standalone mode. Sounds like you had inadvertently changed the mode to WebPlayer?
It might have been. Unity was a fresh install. I didn’t do anything there. But maybe the project was somehow still on webplayer, although i never actually build a web player version with unity 2.
What a weird thing. But that seemed to have fixed the problem.
thanks for all your help guys
Mike