Basad,

The actual code is part of one of our commercial apps, so I can't post it here directly. It's also pretty specific to our app.

The process is not difficult to establish as long as you have a master/slave relationship between your servers.

On each of the servers that you want to sync, you install Unison - this is basically putting Unison.exe somewhere in the PATH and defining the UNISON environment variable to point to a folder where the Unison profiles will be stored. A profile defines the two root paths to sync, as well as any optional parameters. Unison also stores the replica data files there. (small files with information about both sides of the replicas.)

On the Master server, you configure Unison to run as a service using SrvAny. (from the Win2K Resource Kit) The command to run is simply "unison -socket 1479", which starts Unison listening for connections on port 1479. (You can use any free port you wish.)

Then, on the master server, you create a script that runs via the task scheduler on a defined schedule. The frequency will depend on the sync time, but 2-4 hours has generally worked for us. This script uses the FolderModCheck() UDF to quickly determine if any folders in the source path have been modified. (Download the UDF from the Kix Library on my web site.) This leverages the fact that modifying (adding/removing/changing) any file in a folder also updates the folder timestamp. Thus, you only need to compare the folder timestamps and not every file time stamp. This script is something like:
 Code:
$LastTS = GetFileTime('\root\LastChange.ini')
If FolderModCheck('\root', $LastTS)  ; did any file change?
  $ = WriteProfileString('\root\LastChange.ini', 'COMMON', 'LastChange', $LastTS)
EndIf
This basically compares the LastChange.ini timestamp with all the folder timestamps and returns true if any folder was modified later than the INI file. If this is the case, then the INI file is updated.

On the client server(s), on a regular cycle, you run a script that compares the timestamp of the local copy of the LastChange.ini file with the remote copy. Remember, this file is part of the replication and will exist on both sides. If the timestamps match, then nothing needs to be done. If they don't match, then a sync needs to be initiated. You can SHELL or RUN the command illustrated in my previous post, changing the "E:\Data" path to the correct path on your system. The "master" and "remote" are the hostnames of the master and slave servers.

What's nice is that you can put the copy of Unison on two PCs, start the "service" by entering the service command in a command prompt on one computer, and manually enter the slave's sync command on the other computer. You should be able to test the connections and refine the profile settings before putting it into production on your servers. By playing with Unison on two PCs, I was able to work out all the necessary options in just a few hours of tinkering. The Unison manual is only about 30 pages, and the parameters you want to focus on in your profiles are "-root", "-force", "-batch", "-path", and those related to defining log paths.

You can sync multiple slaves. You should be able to make multiple connections to a single listener, but I prefer not to. You can create a unique listener for each slave by creating multiple SrvAny services, with each one listening on a different port. Our commercial product has a single Kix-based socket listener that requests a connection. The sync manager allows up to 10 sessions, and either responds with a port number to use for sync after dynamically starting a Unison listener, or a NAK to reject the request. That's probably overkill for most environments, but we've deployed SWDIST into environments with as many as 400 slave servers hitting a dozen intermediate hosts that in turn sync with a single master.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D