After the brief foray into implementing the JSON thread for network traffic, I have decided that I need to retire my old network thread and update all the old clients to use JSON.
As I developed the Java client, and then later a Universal Windows Program (read this as "Windows phone app") I find myself encoding and decoding the network protocol over and over. My solution is to use JSON on the wire.
With one thing and another, I decided that it was necessary to knock the rust off my Java skills. What better way to do it that create a PLC client in Java?
In just a few hours I had created the application and made it talk with the server, the communications object spins a thread to handle the asynchronous messages from the server, and for each message it generates a command object that is then sent to the main thread for processing. At the moment the only command that is handled is "DEVICE". This is usually in response to "GET DEVICES" from the client at login.
After many years of using XML for the configuration file, I decided that it was time for a change.
Previously plcd was dependent on xerces-c to provide the DOM parsing and creation of the on disk configuration. This worked very well and was stable. I have never been fully happy with the XML format the I settled on and have been thinking about rewriting it for a while. Instead of using XML again, I chose to use YAML instead.
I had a short while over the weekend and decided that plcd needed to become more secure...
Until now, plcd has relied in obfuscation in its dealings with authentication, and bearing in mind that this is about the worst way to do it, I decided that there needs to be some form of real authentication involved. I have decided to use a password field in the network thread which will store the password hash.
I have just realized that there have not been too many updates this year, predominantly because there has not been much happening in the world of plcd! Since the crashes appear fixed, I have not needed to make any changes to the code. I can't think of too many other things I want to change and with time being a finite resource, I have not been just fiddling for the sake of it.
I want to write an Android client so that I can use my tablet as a controller, as well as perhaps embedding super cheap tablets in places that require high density control like the exit doors for example.
As the month of February has progressed, it really does appear that the previous problems with crashing have been fixed. The current uptime has been since the first of the month, previously unheard of!
I am pretty confident that this one is done. Finally I will be able to concentrate on other things needed I really want to make the Android client I promised myself when I got my tablet
With the changes I made yesterday (changing from write to send) it made it through the night, I have since added a line of debug output so I can detect if this was the issue with all of my crashes, but I am pleased this one is done.
As regular readers may realize, I have had problems with it crashing with no messaging. The last two nights, it crashed in a write call with a SIGPIPE signal.
Now, I don't routinely trap signals for the same reason that catch (Exception) is a bad idea, namely they generally mean something bad happened and everything needs to stop so it can be fixed. There are exceptions to this rule of thumb of course, but generally it's no bueno.
As it becomes more and more stable it's becoming more and more common that the only need for downtime is to reload the configuration file.
The reload command will be received from the network thread, and sent to the engine. The engine will cause the ConfigHolder to drop it's configuration and re-read the xml file.
As the ConfigHolder is accessed from multiple threads, this process will need to be mutexed to ensure that there are no attempts to access the class while this process is going on.
