Named pipe down the pipe drain

Last week I talked about named pipes. Named pipes seemed like a good idea on paper and I started this week with trying to find a way to get it to work. The problem was that named pipes works like a server. In order to connect it needs to be up all the time. I didn’t really want a system like that. I wanted the system to be independent, but if the client program was opened and gave new instructions the Unity part would do what you instructed it to. At first the thought was to start the “server” then start the client, but the problem was that the threads seemed to get stuck when quitting, I don’t know if it was because the connection thread was still open until the client program got closed or what it was. I tried troubleshooting it, but debugging is hard to do when running more than one thread.

In the middle of this week I decided to scrap the named pipe system. Reason for this was many, but mainly it was because it was very unstable. Even Unity Editor didn’t seem to like my approach. Sure that could be because I didn’t grasp how to use the named pipe, but it’s difficult to troubleshoot once you get to multiple threads and one thread which is invisible to the debugging system to figure out exactly where the problem lies.

UDP – Solution

Since I had a package system I figured I would reuse that, the choice was TCP or UDP. The advantage with TCP is that you can send files larger than ~60kb, which is something I needed, but at the same time I didn’t need TCP all the time. I decided to do a hybrid solution. Hybrid solution sounds dumb, but what I have done is to make most of the communication go through UDP. So when the user click on a change background button, the background colors are sent through an UDP package. Same thing with smaller packages. If the user on the other hand wants to send a file, what I do then is to send first a small UDP package. The package then instructs the server to open a TCP socket and the client  subsequently starts to connect to the “server” and transmits the data. Once the file is submitted the TCP listener stops listening and shuts that part down. The client does the same.

I said I should have something to share this week, and I sort of do, but since I needed to change stuff mid-week I have not been able to get that much further. Except there are no crashes. I can send files and I can read those files on the Unity end and display those files in the Unity window. I can also change the background to a different color.

Another great thing is that I can start the “server” or “client” independently and it still works. Since UDP doesn’t care if it gets delivered and there’s no real connection. The packages are just being sent and if the receiver is up it receives them. For me that makes it more user friendly and less error prone as well.

For security reasons I added a passphrase with the package that is being sent to Unity so that it only opens if two conditions are met. That the package type is correct and that a string in cleartext (which is not very secure).

Lessons learned

Well, there’s a couple of things I’ve learned. One is that even if Unity has a built-in networking system, you can still create your own UDP handler. Which is very nice, and basically I found out that with a preference change in Unity you have access to all of the .net 2.0. Just change the Api compatibility level from .net 2.0 Subset to .net 2.0 and you have access (Edit – Project Settings – Player). I had to do that for named pipes too, but I forgot to add that last week.

To be able to access GameObject.Find(), gameobject.GetComponent (or GetComponent for that matter) you need to run in the main thread. Which at first didn’t make sense, but once I started thinking about it, changing a component in a thread while the main thread is running update is not particularly wise. Workaround for that for me was to create events. The event was invoked, the setting I wanted change was set dirty and in the next update it was updated.

If you only want to send information and not want to create a connection, use UDP. Even internally it works fine. I don’t know how the speed is compared to named pipes. But from what I understood even named pipes is a network type of stream. Instead of an ip address, it uses an internal protocol. Besides the stuff I want to create is not really based upon speed, it’s more based upon getting the information.

What’s next?

Even though I have done all I set out to do on this project. I mean sending information I want to finish this project. Since next week is Easter I don’t know how much I can do until next week. But who knows.