[Bf-committers] The (un)official render daemon discussion

[Lars Nilsson]

On Tue, Nov 18, 2008 at 9:54 AM, Timothy Baldridge <tbaldridge at gmail.com> wrote:
> The master node would be responsible for managing jobs, transfering
> data, and stitching files. There would be no shared drive between the
> nodes, all data will be transferred over TCP sockets.

Did this with tSNet for trueSpace. Couldn't stand the idea of having
to coordinate mapped drives among machines. One thing I never got
around to was managing a cache of some sort of resources already
available on a node, and only transfer data if it is changed (possibly
removed if some sort of upper limit is imposed on unused resources).

With respect to topology, I think it would be nice if the system
didn't require the machine I'd be working on using Blender to continue
to run blender in order for the process to continue. I'd like it to be
possible to have one or more dedicated machines to doing the rendering
and job scheduling, regardless of the state of my work machine
(powered on or off), once the job has been submitted for processing.
Well, just my own preference, anyway. I realize this would mean not
necessarily having the resulting render being transferred back to the
machine submitting the job, but if it allowed me more flexibility,
it's a price I'd be willing to pay (again, personal opinion, only).

Lars Nilsson