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.
Joe VanAndel wrote:
>
> Jeff Weber wrote:
> >
> > Hi Joe,
> >
> > Are the 3 machines in question identical in regards to OS, LDM version,
> > allows, requests, entries in: etc/hosts, etc/services, etc/rpc
>
> moonbow.rap.ucar.edu, which gives me the error message is running debian
> (potato?). I can't give you more details immediately, because I don't
> have a login there.
>
> linus.atd.ucar.edu, which does not give any error messages, is running
> Redhat 7.2, as does 'spol-nssl', my LDM server.
>
> If someone is familiar with the source code (Russ?), I'd sure like to
> know if it typically takes longer to make an LDM connection if the RPC
> connection does not work.
Hi Joe,
First, my assumption is that the question you are asking is, "Does it
typically take longer to make an LDM connection if the *portmapper
connection* does not work." All LDM connections are via RPC - there are
no non-RPC connections occuring.
Second, my understanding is that you wish to feed from moonbow to some
machine X, and that linus.atd.ucar.edu and spol-nssl each also feed from
moonbow without the delay you're experiencing. Please correct me if I'm
wrong about this.
It is hard to say what is "typical" because configurations across
machines vary so much. I can tell you that an LDM client does not
require that port 111 be available on the remote machine as long as port
388 is available. The client will try port 388 first. If port 388 is
not available, then the client will try to contact the remote portmapper
on port 111. If neither are available the client will give up.
It seems like your client machine X is either not trying port 388 first
or is not allowed there initially but is allowed through later. (It is
also apparently not allowed via the portmapper.) I can't explain this.
Is your name service working properly on X? Can you do a forward and
reverse lookup to moonbow? What happens if you using moonbow's IP
address instead of its name in your request?
You can try ldmping to moonbow from X. ldmping will report the state of
the connection. Here are the states the client will go through in
increasing order:
typedef enum {
H_NONE = 0, /* ground state (empty) */
NAMED, /* initialized, a service is defined */
ADDRESSED, /* we got an network address (nameservice okay) */
PMAP_CLNTED, /* CLNT handle to remote portmap or rpcbind */
MAPPED, /* and we got remote address (port) */
H_CLNTED, /* clnt side handle */
RESPONDING /* clnt is responding okay */
} remote_state;
(The code will jump across the state PMAP_CLNTED on the first try.)
Please let me know the result of your ldmping test. Also, please let me
know the name of machine X, and I will try some diagnostics myself.
If you're really interested in knowing how the LDM is calculating these
timeout values for the portmapper calls you can add a line of code or go
into the debugger to print the value of the "remaining" struct in the
get_pmap_clnt() calls in h_clnt.c.
Anne
--
***************************************************
Anne Wilson UCAR Unidata Program
anne@xxxxxxxxxxxxxxxx P.O. Box 3000
Boulder, CO 80307
----------------------------------------------------
Unidata WWW server http://www.unidata.ucar.edu/
****************************************************
ldm-users archives: