Subject: [IGS-DCWG-47] Re: [IGS-DCWG-46] Proposal for improving IGS data flow From: Dave Stowers Reply-To: dstowers@jpl.nasa.gov To: igs-dcwg@igscb.jpl.nasa.gov In-Reply-To: References: Content-Type: text/plain Organization: JPL/Caltech Date: Fri, 21 Jul 2006 11:28:35 -0700 Message-Id: <1153506515.17583.68.camel@anathema.jpl.nasa.gov> Content-Transfer-Encoding: 7bit Sender: owner-igs-dcwg Precedence: bulk ****************************************************************************** IGS-DCWG Mail 21 Jul 11:28:37 PDT 2006 Message Number 47 ****************************************************************************** Author: Dave Stowers It is good to see that the proposed data flow improvement has been clarified and somewhat simplified (at least from my perspective). The main points I see that remain have to do with the selection of upstream content recipients and the definition of how to handle user notification of replacement files. Pre-picking recipients. (Menu? yes. Static assignment? no): I continue to fail to see why it appears to be necessary to pre-select a primary and backup -upstream- recipient. For example, if two GDC's are down, should not an RDC be allowed to send a file via primary and backup "channels" to the others that remain functional (thereby washing the RDC's hands of further local queuing responsibility, and ensuring maximum distribution with comparatively low latency)? I certainly understand the need for a hierarchy, such that what is "upstream" and "downstream" is well defined (to avoid loops). Perhaps there is a point I am not understanding... Replacement file notification: The suggestion of logging (at each DC level) the receipt of replacement files, I believe, should be the -absolute- minimum required (next is how-to? and what to do with them?). Standardization (name/content), access, and location remain questions; e.g. (as a point of conversation), should DC's that are lower than GDC's in the stream hierarchy push their replacement logs at EOD "upstream" also? Only the modifier (at whatever "stream" level) of a data file can be responsible for providing the replacement rationale (whether a COMMENT line in a RINEX file or a standardized accompaniment file); upstream recipients should not be required to make this determination, but logging could incorporate such info if easily parsed and reasonably defined. Replaced files? I would not expect that the volume of replaced files would be significant, and would propose that no cut off window be necessary or required. I do not propose a naming convention or directory structure for storing the replaced files, but this should not be difficult and I can submit one if there is interest. I look forward to counterpoint or additional commentary. -dave