This is one outline, but you need to be aware of edge cases because networks partition and clocks drift. You should make sure that you gracefully handle (or at

This is one outline, but you need to be aware of edge cases because networks partition and clocks drift. You should make sure that you gracefully handle (or at the minimum aware of) the following cases: 1. Some of your clients lose network connectivity, so when they see an image they respond, but their network drops out. 2. Some clients have incredible clock skew. This can happen due to any number of very improbable events like time zone changes or faulty motherboards, but it does happen. Distributed synchronization really depends on what kind of experience you are trying to provide. For example, if you are showing slides and you want everyone to be "synchronized" you could have all clients poll for the next image, load it in the background, and then notify you that they have it. Once all clients have notified you they have the image you would then push out a command to the clients to display this next image. Your synchronization needs may be totally different if you are trying to provide a different experience. There are some rather fundamental limits on distributed coordination. For a starting point, see "Time, Clocks, and the Ordering of Events in a Distributed System" by Leslie Lamport available at http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf http://research.microsoft.com/en-us/um/people/lamport/pubs/t...