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

[NOAAPORT #LVN-177572]: Mod for NOAAport component of LDM

Hi Gregg,

re:
> Regarding the "sequence number" from the TOC.  In prior discussions with
> Walter Mussante (now retired) who wrote/maintained the socket software, the
> sequence numbers are not the same across the different socket lines.  For
> example, there are socket lines to the SPC, to the AWC/SPC Short-term COOP
> site at Scott AFB,and the AWC/SPC Long-term COOP site at Offutt AFB, and
> the sequence numbers (*in bold below*) are unique to each line (i.e.
> location), for example the most recent Severe Thunderstorm Warning:
> 
> 
> *SPC socket line:*
> 
> Jul 09 21:28:56 comm_svr[32145] INFO: comm_svr_0:     1576
> 20200709212856.668     WMO *92571*  WUUS53 KMKX 092128 /pSVRMKX
> 
> 
> *Scott AFB socket line:*
> 
> Jul 09 21:28:56 comm_svr[10791] INFO: comm_svr_0:     1576
> 20200709212856.130     WMO *8501*  WUUS53 KMKX 092128 /pSVRMKX
> 
> 
> *Offutt AFB socket line:*
> 
> Jul 09 21:28:54 comm_svr[7481] INFO: comm_svr_0:     1576
> 20200709212854.976     WMO *16385*  WUUS53 KMKX 092128 /pSVRMKX
> 
> 
> 
> If I recall correctly from this long ago discussion with Walter, the NWS
> products they receive come from the NCF via a socket line.  Thus, a WFO
> issues a product (i.e. in this case a SVRMKX), it traverses the AWIPS WAN
> to the NCF, the NCF routes the product to the SBN and a sequence number is
> placed on the product as it goes out the SBN, but when the NCF routes the
> product to the TOC the sequence number I don't believe has yet been
> assigned.  When the TOC receives the product and it goes through their
> GATEWAY/FADD system it assigns a sequence number to each outgoing socket
> line, but each sequence number on the various lines do not match up.

It turns out that the WMO header and sequence number are _not_ used in
the calculation of the MD5 signature in the productmaker module that
is part of our NOAAPort code.

Steve and I just had a Meet with Dan to discuss things.  Dan is going to
try and dig up the C code for the process that reads from the socket.
If he can find/get the code, he is going to send it to us (Steve, actually),
and we will see if it can be easily modified so that the products that
it inserts into the LDM queue are compatible with those in NOAAPort.
If this is possible, then this approach is the most attractive (to me,
at least) since it would mean that ingest machines that are reading
from the socket would be compatible with the greater IDD ecosystem.

I've got to run now, sorry...

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: LVN-177572
Department: Support NOAAPORT
Priority: Normal
Status: Open
===================
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.