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

Hi Gregg,

re:
> I discovered why there is a Byte count difference between SBN1 and SBN2
> servers.  It turns out on the SBN1 server I applied the AWC Dan Vietor
> changes to the noaaportIngester productMaker.c code, and the SBN2 server
> had the baseline code.

Ah Ha!

re:
> When we had the GoogleMeet video/teleconference a couple weeks ago I
> mentioned Dan Vietor told me he submitted this change a few years ago for
> possible inclusion into the LDM baseline, and you mentioned not receiving
> it.

Correct.  I do not recall every seeing the note from Dan.  This does
not mean, of course, that it was not received as it may have been
addressed to an individual (e.g., Steve) that was not me.  Or,
quite frankly, I might simply have no recollection of seeing the note.

re:
> This change allows a site ingesting a NWS NWSTG/GATEWAY socket feed
> AND a NOAAPORT feed to have LDM DUP-eliminate products.  It turns out the
> sequence number and CRCRLF between NOAAPORT and the NWSTG/GATEWAY socket
> feed do NOT match.  Dan understands the specifics.

OK.  And, the size of processed products delivered in the NOAAPort SBN are
different from those created by the unaltered code, and this, in turn,
means that each product's MD5 signature will be different.

re:
> Since AWC is using this addition, and SPC will as well, can you please
> consider including this into the baseline?

The following is my view of adopting the code:

The fact that the MD5 signatures for products delivered in the "standard"
way (i.e., via the NOAAPort SBN) get changed makes including the change(s)
difficult.  Why?  The impact of the code change would be for all IDD
participants, but would be particularly disruptive for those sites that
run their own NOAAPort downlink AND are fed from from the IDD.  Getting
everyone to change upgrade their code at the same time would be difficult
at best.

Again, this is _my_ opinion.  Steve may have a different view and may think
of a way that the code mods would not impact the MD5 signatures for products
delivered in the NOAAPort SBN.

re:
> NWS NCO manages the NWSTG/GATEWAY socket feed, and it is possible they
> would setup a socket feed for Unidata.  That is, they already provide data
> for the CONDUIT feed and you are one of the 88-D Level-II top-tier
> providers (i.e. for the Unidata community).  NCO may suggest having an
> "LDM" feed from the NWSTG/GATEWAY but the issue with this is the data won't
> DUP-eliminate if it is flowing into a LDM *also* ingesting the SBN/NOAAPORT
> feed.

Exactly, this is the bit issue at hand.

re:
> Thus, this is why AWC and SPC prefer the socket connection.  The
> socket connection can have whatever data you want on it (e.g. just NWS
> ASCII products, or more), the sockets are what the WMO countries use to
> exchange data.
> 
> Anyway, the code below includes the changes.  I've also included Dan on
> this thread since he came up with the code.

I think that the ball is now in Steve's court...

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.