Blogs

Java client

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.

Configuration with YAML

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.

plcd gets authentication

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.

Not many updates

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.

Crashes appear fixed

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

SIGPIPE

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.

Reload and crashing thoughts

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.

Pages

Subscribe to RSS - blogs