[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20051213: Public ADDE server stratus.al.noaa.gov (cont.)

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20051213: Public ADDE server stratus.al.noaa.gov (cont.)
  • Date: Tue, 13 Dec 2005 15:49:15 -0700
>From: Eirh-Yu Hsie <address@hidden>
>Organization: CU/CIRES NOAA/ESRL
>Keywords: 200512091601.jB9G1w7s009532 McIDAS Solaris 10

Hi Hsie,

re: ADDE remote server access to from Unidata to hail takes a long
time

>The new machine is in a Gigabits network.

UCAR also uses a Gbps network, and we are both on BRAN.

>It supposes to be faster. What do you mean "LONG" time?

For instance, the 'DSINFO IMAGE RTIMAGES' took about 30 seconds.  The
'IMGLIST RTIMAGES/GW-IR.ALL' also took about 30 seconds.  Routinely
seeing the same amount of time for DSINFO and IMGLIST suggests that
there is some sort of a timeout occuring before the connection
succeeds.  The reason I say this is that DSINFO only reads
~mcidas/workdata/RESOLV.SRV entries on the server while IMGLIST reads
the headers for all of the images in the dataset.

As a comparison, the same DSINFO to the NIU ADDE server,
weather3.admin.niu.edu, takes a very small fraction of a second, and an
IMGLIST takes about 1.5 seconds.

We have seen situations were there were persistent 30 second delays
for contact of ADDE servers.  The situation that I am most familiar
with was caused by RFC 931 authorization.  Here is a snippit from
the man page for tcpd on our Fedora Core Linux machine:

RFC 931
       When  RFC 931 etc. lookups are enabled (compile-time option)
       tcpd will attempt to establish the name of the client user. This
       will succeed only if the client host runs an RFC  931-compliant
       daemon.   Client user  name  lookups will not work for
       datagram-oriented connections, and may cause noticeable delays
       in the case of connections from PCs.

Typically user machines have port 113 access blocked, so the
authentication will wait for a timeout period (30 seconds) before
proceeding.

I tried to verify that this is what is going on wrt hail, but I
am currently unable to contact hail at all (either via ADDE
from my machine, or using ping from cirrus.al.noaa.gov).

So, the question is how to turn off TCP wrapping of the ADDE
requests.

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.