On 21 Mar 2004, Dan Kegel <[EMAIL PROTECTED]> wrote: > Martin Pool wrote:
> Sorry, I misread you in my haste. I didn't notice you actually > wanted to make the info available across machines. Unix sockets > are of course no good there. > > >... If I'm going to change the way the monitor works, I > >would rather support better cross-machine views. > > > >As you say, it is just architecturally impossible on Windows. Aside > >from the problems of naming and access control it might be better to > >use an inet socket. Even then, naming might be solved by writing the > >server's address into the DISTCC_DIR. > > > >On a network of a few machines I would like the monitor to globally > >view all the running jobs by all users on all machines. Other people > >might want to monitor that too. That probably implies either a > >broadcast/multicast setup, or a central daemon that retransmits the > >notifications. > > Because of trust issues, I prefer to avoid broadcast techniques. It worries me too. At the very least I wouldn't want it to be on by default. Consider compiling on a laptop connected to a cafe wireless network. Perhaps monitoring across machines is not a good idea after all. On the other hand if the monitoring is purely local it might be simplest just to stick with state files. > By the way, it occurs to me that a local daemon would also be of some use. > e.g. it could hold long-lived ssh connections to the compute servers > (to save on socket startup time), That would be good. It's not so much socket startup as crypto negotiation (DH and so on). I think this can be done independent of distcc. It would be nice if someone did that. > and it could cache knowledge of remote machine status. > But I'm sure you'd think of that yourself if the need arose... -- Martin
signature.asc
Description: Digital signature
__ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
