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.
Anne Wilson wrote:
>
> 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.
OK, so you are saying that all communication is via RPC, and that first
LDM tries to use port 388, and then tries to get a dynamic port thru the
portmapper.
>
> 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.
Sorry if I wasn't clear :
spol-nssl is in Norman, for a field project. It gets LDM feeds from
linus.atd.ucar.edu
moonbow.rap.ucar.edu
eldm.fsl.noaa.gov
Only the connection to moonbow shows the intermittent errors about RPC
failures.
>
> 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?
Yes, forward and reverse name lookup works to moonbow. If the problem
re-occurs, I'll use moonbow's IP address, rather than its name.
>
> 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.
Here's the result:
$ ldmping moonbow.rap.ucar.edu
May 09 19:22:22 State Elapsed Port Remote_Host
rpc_stat
May 09 19:22:22 RESPONDING 0.050303 388 moonbow.rap.ucar.edu
May 09 19:22:47 RESPONDING 0.020030 388 moonbow.rap.ucar.edu
May 09 19:23:12 RESPONDING 0.020033 388 moonbow.rap.ucar.edu
I'm assuming the state can be "RESPONDING", even if the portmapper is
unreachable.
ldm-users archives: