...
Cushy now adds one additional block of code so that you don't have to depend on shared disk. It is simple, low tech, and easy to understand. CAS runs on Web Servers. Web Servers are very good about sending the current copy of small files over the network to clients. The checkpoint file is small, and the incremental file is smaller. Everyone understands how an HTTP GET works. So unless you configure shared disk, Cushy running on a cluster node will periodically fetch a copy of the most recent full checkpoint or incremental file from every other node in the cluster and put it on the local hard disk of the machine. No complex multicast addresses, or timeouts, or port number, or datagrams. Cushy simply reuses the HTTPS that every CAS server already has in place.
Of course, you do not have to use either shared disk or HTTPS if you don't want to. CAS is running on a computer and once every (say) 10 seconds it is writing one of two files to a specific disk directory. If you want to synchronize with its schedule exactly, the timestamp on the file should give you a good target. You can turn off Cushy's own replication and then write your own code in any given language to wake up on the same schedule and copy the new file wherever you want it to go using something as simple as FTP or as complicated as an Enterprise Service Bus. Cushy doesn't really care how the file gets where it needs to go as long as it gets there before the node crashes.
This document still has to fill in a little more detail, and a moderately skilled Java programmer can read the source. However, at this point if you sit down an think it over you can figure out what will really happen and how Cushy will react and recover from any type of failure.
...