VAULT DWELLERS SERVED

Saturday, July 13, 2013

Vault-OS : Architecture Finished

Only took eight years to settle. Of course you have to appreciate that from 2006-2011 I built and ran approximately a couple thousand tests and prototypes in several different languages.

The basic communication mechanism between terminals is UPNP. (Works, or at least demo works)

(Took four iterations of custom protocols before I just ripped off some code from Mini-UPNP open source.)

The basic means for page delivery is Lua Server Pages over HTTP. (Works with simple demo)

The basic mechanism for file transfers is FTP. (Works but sort of slow in DOS, have not figured out why yet)

The basic remote control system is Telnet. (Works but only with a handful of commands, needs more customization for specific needs of remote administrators in a Vault-OS network)

The basic error reporting system in Vault-OS is a custom variation of SYSLOG that takes extended information. (Works but not quite sure how this will integrate with alerts and alarms)

On the VOS terminal itself, all control of sensors and hardware is through an IPC mechanism using the mailslot. Under Desqview (DOS) this utilizes named handles to mail boxes. In Windows, this is mailslots via named pipes. Under Linux, this uses mail URIs for delivery.

On all platforms, an in-memory SQLite table receives and sends mail from the server to all local devices using a cross-platform threaded daemon that runs in tandem with all the INETD functionality listed above.

The mechanism for building controllers via web pages dynamically is not working. I have a custom form builder tool running under JQUERY that is a good start but this requires me to finish building the administrative manager for SQLite and accompanying AJAX services. Still working on this.

It is truly amazing to see the monster I have described above running under DOS with nothing but Desqview 2.00+ and a packet driver. It runs pretty smoothly, too. The Lua pages get served up fast with CGI.

The problem is still the fact that I have nothing running but an increasingly impressive demo. I have ambitions to start compiling the CLIPS library in as an expert system with HTML front end but I already have enough unimplemented functionality to keep me busy.

I had some help from the author of SWSockets in getting the Watcom build to work again under Windows. He has also updated the Linux builds to fix a few small compile time glitches.

Time is scarce and I am supposed to be finishing my roleplaying game. I will progress very slowly on this until that is done but that will likely be completed in the next few months. After that I will devote much more time to this project.

My son and I will be building the new permaculture lab soon and we plan to automate it completely with an initial prototype of VOS.

6 comments:

Russell said...

Sounds intriguing!

How are you handling security?

Did the sockets not work out as well as you hoped?

Alerts and alarms could run off a pub/sub model, if your design can support mailslots in that manner.

Texas Arcane said...

Big problem I am sorting out is that all monitors are passive HTML - what if one terminal has an alert and nobody has a browser open? I think I have to run some kind of hard UI in the background that can pop up on the terminal and either launch a browser with the info or launch a dedicated monitor.

Russell said...

Gotcha.

That's tricky with a passive client.

One thing you could look into is setting up an AJAX call in the base layout that's polling for information, maybe using websockets.

Or you could punt for now and see what happens when you open source the project.

Texas Arcane said...

I have this terminal mode library for text UIs which compiles to more than 20 different hardware platforms. I was thinking I should build this in and have a Lua interface to it. This way it could be infinitely customized to run in the background and always watch for critical information, alerts etc. in addition to regular old tail logs for server and devices.

Russell said...

Sounds like a great solution. I really am interested in seeing the code on this project.

samhuih said...

This is probably not needed and a sidetrack but a guy who was one of the forming member of Audodesk wrote a small programmable library (ATLAST (Autodesk Threaded Language Application System Toolkit) to extend ALL programs. Maybe it will help but maybe not.

http://www.fourmilab.ch/

http://www.fourmilab.ch/atlast/atlast.html

http://www.fourmilab.ch/atlast/

www.000webhost.com