Grid Computing
The software was designed as a client/server system. The client resides on the employees' desktop and laptop systems and performs the calculations. The server runs on a Windows 2000 Server system, doling out the data for calculations and receiving the output. It manages the individual data points, recycling any that have been "checked out" for too long. This prevents the system from developing "holes" in the data resulting from machine crashes, power outages or machines being removed from the network midstream.
Because the client's network consisted mostly of Microsoft Windows 2000 and Microsoft Windows NT machines, we implemented the client as a service (similar to a daemon). Under Windows NT/2000/XP, a service is a program that is loaded when the machine is booted, even if no user logs in. It will continue to run when users are logged out. This is a significant advantage, because it means that the client can run at all times as long as the machines are left up and running, while users can still log out when not using the system, per the client's security policy.
The server application was similarly implemented as a service to run on Windows 2000 Server.
The communication mechanism used is SMB (i.e. Microsoft file sharing). This mechanism was chosen over other options (e.g. implementing a sockets-based protocol on top of TCP/IP) for two reasons:
- Speed of development. By using SMB, we let the OS worry about managing multiple simultaneous connections, handling errors, etc. and were able to use the Microsoft File API, minimizing development effort.
- Ease of review by client's security department. SMB is a mechanism that is well-understood and already approved by the security department. Selecting it allowed our program to "piggyback" on that acceptance.
The application was designed to work only within the intranet of the client, specifically on the LAN at one facility. Had the client needed the application to function over their WAN or the public Internet, other design choices would likely have been made.
The applications were developed with Microsoft Visual C++ 6.0
Automation of Metrics
The application data are output in a tab-delimited file, while data about the nodes are maintained in a Microsoft Access database. Using a combination of batch files and awk, the data is processed regularly (via the Microsoft Windows 2000 Server task scheduler) and reports are generated as ANSI text files. These reports are then emailed to designated recipients.