[distcc] Working on several distcc enhancements (take 2)

[Laurent Calburtin]

> If your network is 100MB, and you've got a reasonable performance  
> switch and high performance file server, network overhead on using  
> a network cache this way isn't particularly noticeable compared the  
> gains in speed by grabbing files from the cache that were compiled  
> by other people.

You mean having the file server accessed by both clients for reading  
and servers for writing? I was thinking about accessing the file  
server from the distccd servers only but you're right one can take  
advantage of it directly from clients. I'll give it a try. I hope  
that the first time penalty (double network transfer of the output)  
will not overcome the benefits.


> As for server selection schemes, I suspect it will be worthwhile to  
> ensure that your load balancing avoids race conditions - it seems  
> likely that the server with the highest score at any given moment  
> might find itself swamped by several eager clients, especially as  
> you get more programmers and continuous integration/build-bot  
> processes.

If a server gets swamped, it won't keep the highest score for long.  
But I agree there may be contention if many clients broadcast to ask  
for the best host at the same time and then all select the same one.
As far as I know, when the distccd daemon is busy, it awaits for  
children processes to exit and one can't know how many clients are  
blocked attempting to connect to the daemon. So when all servers are  
busy, it's difficult to say which one has the less pending  
connections. That information would be usefull for load balancing.

Laurent