/*
 * Argus-5.0 Client Software. Tools to read, analyze and manage Argus data.
 * Copyright (c) 2000-2024 QoSient, LLC
 * All rights reserved.
 *
 * THE ACCOMPANYING PROGRAM IS PROPRIETARY SOFTWARE OF QoSIENT, LLC,
 * AND CANNOT BE USED, DISTRIBUTED, COPIED OR MODIFIED WITHOUT
 * EXPRESS PERMISSION OF QoSIENT, LLC.
 *
 * QOSIENT, LLC DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS
 * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
 * AND FITNESS, IN NO EVENT SHALL QOSIENT, LLC BE LIABLE FOR ANY
 * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER
 * IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
 * ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
 * THIS SOFTWARE.
 *
 *
 *  Author: Carter Bullard carter@qosient.com
 */

/*
 * $Id$
 * $DateTime$
 * $Change$
 */

This is an experimental effort around flow data processing - sorting.

Generally, we want to work with very large files, and so reading
in the complete set of data, and sorting the records in memory, and
then writing those records out, (the algorithm used by rasort.1) doesn't
scale with file size and nodal resources.

In this example we investigate "external sorting" as defined by Knuth,
where the data records are not in internal memory, but are left extant
to the algorithmic context.

So, here we are first going to do a system that generates an offset list
that represents the sorted file.  We don't have to write out the sorted
file, we can write the list of offsets, and squirrel that away if that
is a good thing.

Using basically rasort.1 and rahisto.1 types of processing, we'll support
a "-m field(s)" like option to support multi-key sorting strategies, based
on ArgusFetchAlgorithmTable[x] lookup mechanisms.  This can support everything
except strings, array values, and IPv6 addresses.
