Screen Shots

Source Code and Binaries (jar files)
[Download Latest Stable Releases]
[Tues July 27 19:31:03 CDT 2006]
JAUUS has reached a new milestone!  600 Downloads :)
That may not seem like a lot, but when I first uploaded this application I actually didn't expect anyone to ever use it :)  Thanks all for the support!

[Wed Aug 17 12:57:50 CDT 2005]
I've been working on a newer version of TagReader, now updated as TagAttributeReader, since the next full release of JAUUS will support a new server.properties file format.  It's nothing special, but I will be moving all of the maintained modules into a single xml file (server.properties).  In doing so, I had to rework the way the application configuration presently worked.

This is due in part to the new web-driven config file.  The code I've just completed allows an admin to point JAUUS to a web-site and can read the xml output.  In addition, for high-priority application multiple servers can be listed in the client.config version. 


[Thur Jul 28 14:20:11 CST 2005]

Going to add some the new web-features.  This new release will (hopefully) allow both the server and the client to be configured from a remote site and will also allow for multiple servers to be listed in case one, or more, does not respond.

Java Application Update Utility Software (jauus)
What is JAUUS (Java Application Update Utility Software)?

Short answer: Jauus is a software patching programs that works over the internet by making a single TCP connection to the host server. It works on any java supported platform for -ANY- language or type file; ASCII, binary, java, VB, C/C++ Perl it doesn't matter. The client/server see each file as objects and pass them over the network as such.

Long answer: Appending to the short answer, jauus works like this. A connection is made to the server, some handshaking and communication is done and the server looks up the requested application file structure. A global checksum is calculated as each files checksum is generated. This information is then passed to the client who does the exact same thing on his end. The master checksums are compared. If they do not match then each file is individually checked against the master list. When the file fails to validate or does not exist that file is then downloaded from the server. When the validation process is over the client checks the config file and determines if the application is to be started and if so what command to execute.

What's the inspiration? I had written an application for the support division that was constantly being changed for one ( I didn't remember to I thought I told you about that ) reason or another. That's not so bad, I'm paid to do that but what got under my skin was not everyone one is support would read the update emails and they'd wine about "it still doesn't sort by blah-blah". Anyways...I needed a program that they could run that would verify the files they are using and make sure they -always- had the latest version. So Jauus was brought to life.

Flow:  (Client Side Flow Diagram)
Client: Initializes and loads the config file ( in the final release it will be obfuscated with a simple hash ).
Connects to the patch server and request the checksums
Server: The server reads in the application name, loads the config file for that application and builds a container of CheckSumItem's and returns it to the clients.
Client: Compares the local PAK checksum to the server PAK checksum.  If they match, the server checks the config file (it's located Server Side and is handed down ) . If the application is to auto-start, the new application is ran. Otherwise the application exist
Client: If the PAK checksum fails. Each individual checksum is compared. Upon any failures the files is retrieved from the server.
Server: Before returning the requested file, it is validated against the file hash to ensure that it is in the list.
Client: If the application is to auto-start, the new application is ran. Otherwise the application exist
The Server.properties file (located under: <install directory>/src/integrity/server ) contains the configuration settings for the server. This is described in detail under the Configuration link.
In brief, the server.properties sets the working directory for the <applicationname>.xml files.
It's very short and very simple.
  • Add the ability for the server to request that a log file (or some output file) be returned to server
  • Update multiple applications with a single client
  • Obfuscate the <application-name>.xml file
  • check into some form of SSH or encrypted connection (not sure on that one)
I presently work as a Sr. Application Architect for an ATM transaction processing company.  I received a B.S. in Computer Science and a Masters in Information Technology specializing in Network Security/Computer Forensics. Linux is my operating system of choice and I work hard to keep on top of the new and exciting changes that Java brings to the development table. I am a strong advocate of the Open Source movement and remain very thankful to the SourceForge community.

SourceForge.net Logo