--- [EMAIL PROTECTED] wrote: > Exactly. > > I should have been clearer. The default windows/cygwin client is > neither correct enough (cygwin's fault) nor provides all the > metrics we want (in fact, because some of our farms are not just HPC > farms, we want some other metrics as well). I remain grateful to > whoever developed it, none-the-less. >
As I said, I do not know the Cygwin client very well. > I am not a windows man, but we are looking at the possibility of > developing a fully native (no cygwin) client ourselves. The reason > for the TCP question is that my feeling was that it would be > much easier to produce a native "first pass" windows gmond client > deliverying TCP only, rather that all that clever UDP stuff as > well. > Not really liking Windows myself, I believe the contribution of a native client would be very welcome. > But of course with the TCP route, I have fears of scaling. But there > is a GEM in Martins reply (and a Doh moment for me), in that I > assumed that every node would have to be polled by a gmetad to get > the cluster info. But you remind me this is not so, I can do the > structural equivalent of the udp unicast to a head node using TCP > to a head node, that gmetad then interogates. > > Have I got this right guys? > Unfortunatelly I think the answer is no. I made the mistake to somehow associate gmond "unicast" with "TCP" which is wrong. Communication between the gmonds in a host group is always UDP. One ore more clients listen, while all push their data out (either multicast, or unicast). But you are right that gmetad only needs to communicate with the heads of the host groups. This communication is TCP. > And the other thing for the community is asking whether anyone else > out there is considering developing a native windows gmond. > not me :-) Cheers Martin ------------------------------------------------------ Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
