On Sunday night I finished grading program #1 for the Data Structures & Alg. II class.... *deep sigh*
Dr. Jonyer and I didn't talk about the system last week, so I had a few days of self-directed development on my system. I took the time to add a little polish in places that needed it. First, I added a few new user tools for listing the hosted projects, cluster members, and tasks on the server piece. Then I added syslog support, which I prefer over dumping everything to the console. Finally, I streamlined a section that I had breezed over for the initial prototype demonstration.
The section I worked on initially worked in the following manner. The server assigned the clients tasks, the client would then request the needed files for its CPU architecture. Next the server would see if it had the files for that architecture and deliver them, otherwise send a "no support" message. The problem was the first task in the queue wasn't guaranteed to use files supported by the client's architecture, so I was assigning tasks to clients that the clients couldn't complete. It was a cheap and dirty approach that worked well enough for the demo, but wasn't the most efficient use of bandwidth and the client's time.
Now I do it the right way. When the client request a task it sends its OS and Architecture information upfront, then the server can see if there are any tasks having files supporting the client's architecture. If there are tasks but not tasks that support the client's architecture, I send a "no work" message. This way I don't have to make the client handle clearing tasks when there is no file support for their architecture. In other words, they won't be assigned a task unless there is support. Overall, this little bit of polishing doesn't seem like much work, but it took the whole day to do and should save me a week or more of work latter. I.e. coding up the job clearing code would take a week or more to do. An ounce of prevention is worth a pound of cure.
