Want to make some minor FADProgress changes

[rsbriggs]

Meer,

I want to make some minor changes to FADProgressd. It would be useful to allow it to tell me the status of a computer - up or down. Currently, if the FAD files aren't found, it won't send any packets to the GUI.

I want to break out the UDP packet send into a small helper function that is called, rather than being directly embedded in the FAD file parsing stuff. Once that is done, it will be possible to call that function from this spot in doProgress():

if (fp == NULL) // check for probs
{
	//reportError(false, null, sFile + " not found");
	strcat(sProgress, sPACKET_TYPE_PROBLEM);
	strcat(sProgress, sPACKET_DELIM);
	sprintf(sReport, "WARNING:  error opening file %s.  Continuing...\n", sFile);
	report(sReport);
	return FALSE;
}

What I want to end up doing is formatting and sending a (basically empty) "ping" packet just before the "return FALSE" here. That way, the GUI will update to show the time that the computer last communicated and let me know the computer is alive, even if it isn't running FAD.

It's a minor change that wouldn't affect the basic functionality any, but might allow for various expansions in the future. You could then call the packet send function from other routines - perhaps one that knew, for example, how to deal with an SOB file (if someone wanted to take the time to write something that parsed it. Doing that would involve adding a new 'S' packet type to the program, then modifying the GUI to deal with "S" packets.)

Anyway, it just seems like a simple mod I could make to allow for additional functionality to be added in the future, if you didn't mind.

Edit:

My next step after that little change would be to allow the linux version to read from a .ini file, too, instead of depending exclusively on command line args.....

[MerePeer]

Thanks for the suggestions and ideas. I agree the use case you point out (cant locate server.dat) could be handled better so we had more information in the GUI.

I took a look at this (server.dat doesnt exist) handling and I see it is actually has some leftover code from an earlier version where I did send a packet for this condition, with the type of packet_type_problem: as you can see it is actually strcat'ing onto an uninit stack var (not good) and then doing nothing with it at this time. The reason I took it out was that without a server.dat you dont know the name of the machine(s) for which the packets are to be sent on behalf because the names of the nodes are determined from within the server.dat. So if we wanted to send a "its not running fad but its still here" packet we ideally would send that packet for each node that the server is/was hosting, but that won't be possible because we dont have the server.dat. I think what could be done instead is to just pass the server name (cfgThisName) and the packet_type_problem, then change the GUI as well to understand it needs to locate all nodes for which the incoming packet was the server-for (if any were previously shown...) and change their status, noting that if none were previously shown then we would still have no indication in the GUI.

Other thoughts:
-- I guess we could break out the packet send...but since its only one line of code (sendto call) and the args are already globally available, I'm not sure its worth bothering.
-- I'd like to keep this application limited to the FAD project. I previously tried to host multiple projects in one status-sending executable and it gets too messy to maintain as well as deploy because it means when a new version comes out for one project that the other project must update for no reason, doubling the testing and other efforts. So perhaps you want to consider grabbing the code and branching it into your own SOB progress-thing? The d2olprogressd is an example of a close cousin.
-- The next enhancement I was going to tackle (August?) was to retreive, send, and display the IP # of each node. This was a request from 2 months ago from Bok because some farms dont have names that are as easy to work with as I/P #s.
-- I implemented the .ini for the daemon under Win because its very difficult to pass args into a win Service. Under linux we have shell scripts running the binary that are text files that can be just as easily modified as if we had .ini files, so there didn't seem to me to be an immediate need for supporting a .ini as well as the existing command args (see PROGOPTS= in /etc/init.d/u_fadprogressd file). If we do support a ".ini" then I'd prefer we adopt a ".conf" file which normally would reside in /etc; also /usr/local/bin /usr/bin dont normally have .ini files in them. {That reminds me, I think I only have a Debian /etc/init.d start/stop script and we really should have a RedHat one too...}.