Overview

The system uses the notion of master(s) and slave(s). Masters produce work for slaves to do and return the results to masters.

The description of the system claims that it is "(very) flexible". What I mean by that is that the system itself doesn't impose a lot of restrictions on how it can be used.

For example:

• Have the same computer be both a Slave and a Master.
• Have multiple instances of Slaves running on the same machine, each on a different port.
• Have one Slave reporting to a number of Masters depending on e.g. the result of running some TaskUnit. - Trivially set the system up to have (theoretically) infinite number of "layers" with a layer either being slaves or master etc. So you could have a master produce taskunits for slaves which in turn produce more taskunits from the results for other slaves and so on.
• You could even have a [work-production-graph](work-production graph) with cycles in it.

While designing the system, I focused on easy and quick deployment among other things. The system only requires one config file and that too only on slaves to tell them where to contact masters. In the future, I might introduce the notion of config masters which all the do is configure the slaves and that way the slave only has to contact one master and the system will be configuration free. That will also allow e.g. to assign taskunits based on the kind of hardware a slave has e.g. send graphics-heavy taskunits to slaves which have dedicated GPUs etc. without having the system user configuring anything.