Wednesday, August 19, 2015
Vault-OS : Global Control Protocol Over ASN.1
I applied some of what I learned at work today to some source code I had at home and successfully compiled the entire, unique communications and command protocol for VOS from the open source ASN.1 compiler. It is still in flux so chances are stuff will be added to it eventually. Theoretically this binary will support VOIP, streaming video and many other kinds of devices running daemons. The protocol is a very generic digital control and command set that provides a similar functional environment to BACNet. I think station-to-station telephony is an important part of VOS and provision for this capability should be in there. You should be able to instantly mount a headset and talk over VOS to another workstation with a central directory. This is a ways off but the possibility will be there in the messaging protocol.
My time is limited lately, very long commute - but I was able to send and receive messages over web sockets in this format. I think I have the holy grail for supporting different protocols for the daemons from CAN to RS-485 all the way around. I also cracked the functionality barrier to couple to Lua scripts from ASN.1 with JSON syntax. There is a very simple way to control the parallel port under Win NT/2000/XP for a daemon using this method.
I have this crazy idea for daemons to support calls over Websockets to the server as a very easy alternative for extremely small devices. I'm talking thimble sized devices talking over WebSockets to the main server all-in-one. Devices like BASIC Stamps that don't even have room for TCP-IP stacks but can write a small stream of bytes as a protocol over Websockets and parse the response. Where would this come in handy? I am envisioning little systems monitoring keypads at entryways, tiny devices designed to control pumps and water/fuel metrics, maybe a small VT-100 terminal with a limited command set inside a staging area. A lot of these devices could not run BACNet over IP but they could run my little subset which is very generic.
At my current job there is no requirement for a graphical UI for the server monitoring itself on the host machine but this is a great way to supply that feature and keep it totally decoupled from the server itself which can operate even without a display device if desired.
I think running on Windows NT with numerous daemons this server will rarely consume more than 4 megs total RAM and should launch nearly instantly as a service if needed.