mjhjmtu

A colleague of mine has done great work and is familiar with linux. He is on the verge of solving a problem the vendor couldn't support for viewing medical images.

In the vein of learning linux better myself, I proposed to "invert" his initial design. I dont want to request he scrap his work, so I want to build off his success and do a side project to learn a bit of linux. If I'm successful, I think my proposed design is more sensible from a support/system administration standpoint.

Here is what we currently are doing and what I had proposed we change to:

To describe his current setup:

• Images are sent to the "hub" server which indexes them with sqllite (not shown)


• all the clients (who have cygwin installed) periodically query the database to check for new additions using a combination of cron/rysnc


• when a new image set is found, the client does an rsync to a local folder


• because the db doesn't have a flag for when the incoming images have completed, we are storing what was rsync'd and checking for modifications to do an additional rsyncs


• we then dump the local client data at midnight and start fresh the next day

What I would like to do is the following:

• Invert his design, essentially. This will remove the need to install cygwin on all of our windows boxes (should they die/be replaced/etc)


• when the DB gets a new file, it looks to its list of mapped drives (which are shared SMB folders of the client PCs) and does an rsync to them


• all the same logic he wrote for checking for modifications will be the same but with the server pushing out the updated files

My questions are:

• Is rsync capable of running and properly maintaining a queue of requests to rsync out to the clients?


• Is there a more effective way to monitor for the modified date to trigger pushing out new files?


• Is the combination of cron and rsync enough to make this work? We just set cron to run every few seconds to run the above checks for modifications and run an rsync when it is satisfied