Filename: SGS_Daemon

Introduction

  This file gives a brief overview of the SGS daemon.


Starting the daemon

  The daemon can either be started with zero or one argument.  Here is the
  informal syntax:

	sgsd [data path]

  The 'data path' optional argument represents the path where the sgs daemon
  will find the 'data' directory which contains the 'defs' and 'values'
  files, containing respectively the sequence definitions and current values.
  Invoked with no arguemnt, sgs will use the root installation directory with
  the string "/data" appended to it as the location to store these files.
  The installation directory is selected when running the 'setup' script,
  prior to the package compilation.


SGS Daemon's Architecture

  The sgsd daemon, or the Sequence Generation Server as it is also called,
  is a process that runs in background.  It is accessed through the TCP/IP
  sockets mechanism provided by Berkeley UNIX facilities. You can learn more
  about this mechanism in "Using C on the UNIX System" by David A. Curry,
  a Nutshell handbook published by O'Reilly and Associates, ISBN 0-937175-23-4.

  At launch time, the daemon currently reads in _ALL_ sequence definitions
  and current value for every one of them.  When a client establishes a 
  connection to the server and sends a request for the next number in a named
  sequence, the daemon looks at the number of values that are still in the
  memory cache.  If that number is zero, the daemon opens the values file,
  reads n sequence values, where n represents the number of entries that this
  particular named sequence keeps in it's cache.  If the number is greater
  than zero, the current value is incremented by the increment that is set
  for the sequence, the number of entries currently in the cache is
  decremented by one, and the new current value for the sequence is returned.


Stopping the daemon

  The daemon can be stopped by simply killing the process.  Since it does not
  keep open file descriptors, the daemon is fairly stable, and I have never
  experienced data corruption.  Of course, I cannot garantee the data
  integrity in case there's an earthquake =:^)

