One of the first things I had to do, was figuring out how to connect to an external server via Unity client using a TCP/IP socket. It took a lot of searching to find help on this issue but I did find it eventually. I’ve added links to my files here so you can view/use them.
So to get your Unity application to connect to an external server via TCP/IP socket, you will need the following:
TCPConnection.cs – the connection handler, server communications
socketScript.cs – the script attached to one of the GameObjects in Unity (I used the Main Camera). We will use this script to attach a copy of TCPConnection.cs to the Camera as well.
I’ve added comments to the important things, hopefully they make sense.
If you want to use javascript instead of C# for your socketScript and application in general, remember to move the TCPConnection.cs into the /Assets/Standard Assets folder (just create it if it doesn’t exist) for it to work. In my case (since I used C#, I just put them both in the /Assets/Scripts folder).
I wrote my own very basic C++ windows socket server to test this. When interacting with server, make sure that your server returns the newline command after every response, otherwise your unity client will be left to hang (until the server disconnects). For our server we had to use \n but it depends on what type of server you are running.
If you want to have multiple connections (like for most games, you’ll have the login server and the game/world server), you just got to add another instance of TCPConnection.cs to your socketScript.
Moving notice:
I wasn’t gonna bring over both posts separately, so this already includes the updates for multiple messages at once and using the split method to separate them. Also I’m now hosting these files here on this actual server instead of my synamicdsolutions URL.
I found this on Google and it’s proven very helpful, I’d like to just point on one thing that almost caused me to think that there was an error in Unity.
In TCPConnection.cs, under the readSocket method, you need to add:
result = result.Trim(‘\0’);
right before the return statement. This is because the string is originally created from an array of the buffer size of the socket, and thus has plenty of null characters at the end of the string. This will remove them so you can get a correct output.
If you don’t do this, you get weird behavior. For example, if you call result.Length, you get 65536, or whatever your value of mySocket.SendBufferSize is. Then your string length is obviously incorrect.
Thank you for pointing that out. We’ve used this code for a while with our server so we haven’t got any issues with those null characters, I think this might also depend on the server output. I remember doing a lot of research on this when originally written a few years ago, so different servers send different line endings, so it’s possible ours does not send those null characters, I can’t remember now which server sent which but it’s definitely good to have those trims there regardless just to avoid any issues.