JSON continues to be the protocol of choice

Submitted by toftat on Mon, 2016-08-15 22:36.

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.

JSON enters the mix

Submitted by toftat on Mon, 2016-07-25 13:01.

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.

Java client

Submitted by toftat on Mon, 2016-06-13 10:01.

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

Submitted by toftat on Wed, 2016-01-27 13:45.

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

Submitted by toftat on Mon, 2014-11-24 08:37.

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

Submitted by toftat on Wed, 2014-05-28 10:38.

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

Submitted by toftat on Sat, 2014-02-22 18:05.

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

Follow up on SIGPIPE and a webservice front end

Submitted by toftat on Wed, 2013-12-18 10:40.

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.

SIGPIPE

Submitted by toftat on Tue, 2013-12-17 11:57.

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

Submitted by toftat on Sun, 2013-12-01 17:27.

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.

cowshed.us

plcd