I am planning to start working on adding load management enhancements ...
3) on startup, distcc determines appropriate server to send request to a) poll all servers in host list - wait until all respond or 0.1 seconds, whichever comes first b) multiply connection count by weight, take minimum result, send request to that server ...
The design may be simplified by choosing a coordinator and not changing distcc or distccd. This seems to have been the design philosophy for distcc and ccache -- don't complicate distcc or distccd if some other program can get the job done as well.
The coordinator can receive pushed load information from clients that front/masquerade distcc, much like ccache and distcc themselves can masquerade cc. When distcc is invoked by the coordinator client, the desired host is specified on the command line as the preferred host, and can fallback to localhost if there are network problems.
Here's a scheme that does what you're suggesting in a slightly different way.
I've been toying with the following idea, which combines load balancing with fsh-like connection caching. Let's call it lbfsh. One scenario would be: running "lbfshd $SHELL" would start a local server listening on a local-only socket, put that socket's url in the environment as LBFSH_URL, and run a shell; when the shell exited, the local server would exit. The command "lbfsh host cmd ..." would ignore the host argument, connect to $LBFSH_URL, then execute cmd ... by passing it to the local server rather like fsh does, except that the local server would pick the remote server to send it to. To use this with distcc, you'd set DISTCC_RSH to 'lbfsh', and set DISTCC_HOSTS to anything at all; lbfsh would ignore the host argument.
- Dan
__ distcc mailing list http://distcc.samba.org/
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
