Files
@ 1c70cb48bb28
Branch filter:
Location: DistRen/etc/distrencommon.conf - annotation
1c70cb48bb28
1.7 KiB
text/plain
-- changes to frame_finder() --
-changed for statement to a while statement
Mentally preparing self to change the entire frameset structure to 2 arrays instead, because I can't create a structure array without pre-defining the amount... if u can I don't know how. And that means I would have to make it 30k or something depending on how crazy people get with animations, which would waste a ton of memory.
-changed for statement to a while statement
Mentally preparing self to change the entire frameset structure to 2 arrays instead, because I can't create a structure array without pre-defining the amount... if u can I don't know how. And that means I would have to make it 30k or something depending on how crazy people get with animations, which would waste a ton of memory.
67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 67c77fdf3f11 | /*
Configuration file for distren.
Currently, this file is being prepared as the goal for this project. For instance, the ability to support connecting and communicating with servers is suggested by the server sections.
*/
/*
currently, server's are only supported rudimentarily. If a job has n frames and there are s servers, n / (s + 1) frames will be sent to each individual server and also rendered on the machine the job was submitted to. There will be no recursive distribution of jobs, but I want to make that possible in the future. AND, I want job IDs to have significance based on 1: the files, 2: the versions of software used to render just like git, mercurial, or bazaar's commit IDs have significance. This will allow global distribution of renderjobs without requiring central servers to coordinate the jobs - a network only need be distributed. And complex algorithms based on timeouts and completion of jobs should allow slow servers to reassign jobs to fast ones and, possibly, find shorter routes to return the resulting images to the original job submitter.
Just a pointer, for the multiple server architecture, we would need to designate one server as a "master" server to avoid obvious issues. We can code it flexibly though. --Normaldotcom
I don't know what ``obvious'' issues you're talking about ;-) --ohnobinki
*/
server protofusion
{
hostname = "protofusion.org"
username = "distrenc"
/* method's use is not implemented, ssh is the only option atm ' */
method = "ssh"
types = {"submit", "distribution"} /* submit means it accepts jobs, distribution means it can host files */
}
server ohnopublishing
{
hostname = "ohnopublishing.net"
username = "distrenc"
method = "ssh"
types = {"distribution"}
}
|