NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Carl,
> To: Unidata Support <address@hidden>
> From: Carl Sinclair <address@hidden>
> Subject: Re: 20040113: monitoring question
> Organization: OU/CAPS
> Keywords: 200401151740.i0FHeZp2018016
The above message contained the following:
> We are looking for a more efficient way to monitor connections via LDM.
> We are not apposed to writing additional code, but we certainly want to
> explore our options first. We want to avoid sifting through the log
> file as well. Do you have any documentation for the low-level
> communication of the LDM client-server model? That might allow us to
> sniff what's happening outside of LDM. Thanks!
I'd start with the description of LDM behavior at
http://my.unidata.ucar.edu/content/software/ldm/ldm-6.0.14/basics/behavior.html
and then investigate the rtstats(1) program. This program has a
man(1)-page in the distribution. You might be able to modify rtstats(1)
to do what you want.
I'd then give me a call. :-)
I'm experimenting with putting the LDM codebase under our experimental
GForge system (www.gforge.org -- it's similar to SourceForge). Are you
interested in becoming a developer?
Regards,
Steve Emmerson
LDM Developer