[McIDAS #XRR-599672]: FW: Please remove port 23 access from shu.cup.edu, and add ports 22 & 112.

Hi Samuel,

re:
> I'll ask if our network guy can add port 22 to the outside world for only
> 128.117.140.*.

Thanks.  This is likely to be useful for you in the future...

> While I'm at it, I'll ask him if he knows of any limitation for port 112 on 
> the
> 128.117.156 subnet.

Port 112 appears to be open to all.  Port 22 was apparently closed to
machines on the Unidata 127.117.156.* subnet.

> I'm not sure why I had LDM ingesting CONDUIT, I don't think we need it, but 
> again
> I'm not a weather expert, Originally we were only interested in the following 
> feeds:
> > > DDS
> > > PPS
> > > IDS
> > > UNIWISC
> > > FSL2 (FT7, PROFILER)
> > > AFOS
> > > NMC2
> > > DIFAX
> > > NLDN
> > > GEM
> > > NNEXRAD
> > > NEXRAD2

NMC2 _is_ CONDUIT.  The list of feedtypes available in the IDD AND their
aliases can be found in:

http://www.unidata.ucar.edu/software/ldm/ldm-current/basics/feedtypes/

Also, specfying any one of DDS, PPS, or IDS is the same as specifying 
IDS|DDPLUS.
The individual feed names are a holdover from a bygone era.  Also, missing from
this list is NIMAGE, the GOES-East/West image sectors in NOAAPORT.  Finally,
AFOS is archaic; there is no data available on the IDD in the AFOS feed.

So, I think that the list of feeds that you want initially is:

IDS|DDPLUS - global observational data
HDS        - model output from NOAAPORT (also known as HRS)
  WMO == IDS|DDPLUS|HDS
UNIWISC    - Unidata-Wisconsin GOES East/West image sectors 
  UNIWISC == WMO|UNIWISC == IDS|DDPLUS|HDS|UNIWISC
FSL2       - wind PROFILER data
DIFAX      - Difax-like products generated at the University of Wisconsin
NLDN       - National Lightning Detection Network (NLDN) lightning data from 
SUNYA
GEM        - model output from the Canadian Meteorological Center (CMC)
NNEXRAD    - Nexrad Level III radar products from NOAAPORT
NEXRAD2    - Nexrad Level II full volume radar data

At some point in the future you might want some data from:

CONDUIT    - high resolution model data from NCEP

Your ability to get some/all of the CONDUIT data will depend heavily on your
network connectivity and your system capability.

To get an idea of the relative volumes of data in the various datastreams
available in the IDD, please check out:

Unidata HomePage
http://www.unidata.ucar.edu
  IDD
  http://www.unidata.ucar.edu/software/idd
    Real-Time IDD statistics
    http://www.unidata.ucar.edu/software/idd/rtstats/
      Statistics by Host
      http://www.unidata.ucar.edu/cgi-bin/rtstats/siteindex

From the last page, you can find your own machine, shu.cup.edu, and all other
machines participating in the IDD that are reporting statistics back to us.
The Unidata-maintained toplevel IDD relay, idd.unidata.ucar.edu, is a site
to check to see how much data is available in a particular feed as a function
of time.  You can compare your ingest statistics with those from 
idd.unidata.ucar.edu
to get a quick idea if you are getting the data you think you should be
getting:

http://www.unidata.ucar.edu/cgi-bin/rtstats/siteindex?idd.unidata.ucar.edu

The links at the bottom give:

Cumulative volume summary
Cumulative volume summary graph

breakdown the volumes of the various datastreams textually and graphically,
respectively.  The other links show various items of interest for individual
datastreams.  If you click on the volume link for CONDUIT, you will see
that CONDUIT contains over 2 GB/hour of data on average with peaks above
4 GB/hour.  CONDUIT is the highest volume data stream in the IDD by far.
The second most voluminous datastream is NEXRAD2.  Sites getting both
of these feeds need to have BIG network pipes and well configured machines
to be able to handle ingest/decoding.

> I tried to limit our NEXRAD feeds to the eastern U.S. by using the regular 
> expression:
> "K2|KA|KB|KC|KD|KE|KF|KG|KH|KI|KJFK|KL|KM|KN00|KO|KO|KPIT|KPHL|KR|KSYR|KT|KT|KUUU|KVSF|KWAL|KYNG"

Yes, I saw this.  I also saw that you are attempting to feed it redundantly.

> I'm sure there is a better way to limit the traffic, but that was what I came 
> up.

Your regular expression could be shortened a bit and made somewhat more 
readable, but
if it does the job, there is no reason to change it.

Cheers,

Tom
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: XRR-599672
Department: Support McIDAS
Priority: Normal
Status: Closed