Input/output structure, decoders and encoders
|
|
File and stream IO operations are represented using a virtual gio class which can be replaced in run time by an appropriate inherited class. In real-time this is represented by gtcp (TCP) implementation and gntrip (NTRIP) implementation (which is derived from the gtcp by re-implementing the initialization procedure for an authentication. Such implementation supports both real-time and post-processing approaches in a unique way for all user applications. The internal buffer of gio class supports the handling ASCII as well as BINARY data.
Additional special file classes - giof, glog and gxtr were implemented for additional IO operations providing time-specific file-masks, generic logging, summary extractions etc. The giof is also used internally in gio class for store/provide data between data streams and raw file. These are applied e.g. for logging stream content in ntrip-client or feeding data input in ntrip-client. The basic scheme of all IO classes is plotted in the figure (grey backgrounds).
If input data decoding (or output data encoding) is required, the gio object (or correctly its inherited object) is linked with any object derived from the generic gcoder class in order to provide specific decoder or encoder. All gcoders supports both stream and file IO operations while the main difference typically consists in handling of header and data parts. This is done separately in each decoder/encoder classes. The header operations are usually active only in the gfile class.
All encoders/decoders are derived from a single virtual gcoder representing various data, models or products formats and are plot in figure with a blue background. When gio instance is called with the decoder (encoder) capability, it needs an access to the relevant data structure which are plotted with a green background the figure left (bottom) and on the next page (figure 'data structure').
Figure left (bottom) shows the strategy to implement access to input data and products as well as output results. While post-processing solutions are based on files, real-time processing requires continuous data/products streams. In the first approach files could be read at once before the processing start up, but the second approach requires buffered input/output operations maintained during the whole run of the processing without disruptions of streams. Any operation on continuous streams could be handled using either with blocking or non-blocking access. The former is easier to implement, but requires a multi-thread application where each continuous stream is handled by an individual thread. The latter can be used also in a single thread application. By designing relevant classes as thread-safe objects within the G-Nut, both approaches are generally supported.