DataMuseum.dk

top - metrics - download

    Length: 6064 (0x17b0)
    Types: TextFile
    Names: »implementation.tex«

└─⟦3d0c2be1b⟧ Bits:30001254 ISODE-5.0 Tape
    └─⟦eba4602b1⟧ »./isode-5.0.tar.Z« 
        └─⟦d3ac74d73⟧ 
            └─⟦this⟧ »isode-5.0/doc/quipu/implementation.tex« 
└─⟦2d1937cfd⟧ Bits:30007241 EUUGD22: P.P 5.0
    └─⟦35176feda⟧ »EurOpenD22/isode/isode-6.tar.Z« 
        └─⟦de7628f85⟧ 
            └─⟦this⟧ »isode-6.0/doc/quipu/implementation.tex« 

TextFile

\chapter {Implementation Choices}

\section {DSA Structure}

Whilst the operation of a QUIPU DSA is fast, its
startup procedure is not, due to reading all of its data from a text file on
disk.
This long startup means that applications must be able to use
multiple DSAs, to prevent lockout whilst the local DSA starts up.
Also, the process structure of DSAs must be static.
To provide a system with reasonable availability, particularly in view of
the system's ability to perform extravagant searching, the basic
DSA must be able to handle multiple calls.
For this reason, apart from conformance issues, the DSA will be inherently
asynchronous, and will need to have its own internal scheduling.
Initially, this can be simple minded.
However, we are providing a framework for a system which is very
sophisticated in this area.

The basic approach of the DSA is to have two (conceptually) co-routined modules, which are
interfaced by in-core C structures.
The first module is the DSA engine, which resolves inbound queries either
by looking them up in its in-core data structures or by generating further
queries.
The second module is the protocol engine.
This is responsible for opening and closing calls, and for mapping between
OPDUs on the network and C structures to be handled by the DSA engine.
The interface provided to the DSA is largely independent of DAP vs DSP.

\subsection {Memory Structures}

There are a number of structures which are of particular importance.
They are summarised here:

\begin {itemize}
\item
The Entry is as the basic component of the in-core tree, which is linked
upwards and downwards between parents and children.
The tree always starts at the root, even if there is no information beyond
the RDN present.
Where an entry corresponds to the base of an Entry Data Block, the parameters
of the Entry Data Block are present.
Siblings are linked in a chain.
Each entry is represented by a `C' structure, which contains:

\begin {itemize}
\item
Information on the linkage (hierarchical, and between siblings).

\item
How Entry Data Blocks are managed.

\item
How the ``special'' attributes (ACL, Schema, Alias, Password, DSA location
info) are held.
\end {itemize}

\item
There is a structure associated with each connection.
This is used to represent actual and desired connections.
These structures are linked into a list, and are the key point for the
protocol module.
They indicate a list of operations and tasks associated with each connection.
When the DSA engine needs a connection, it will see if one is already
open to the DSA in question.  If it is not, a connection structure will be
created, which the protocol engine will act on in due course.
Similarly, the protocol engine will close down unneeded connections, possibly
after some (intentional) delay.

\item
There is a Task structure associated with each query which arrives.
This holds the {\em full} state of the task, so the the DSA can switch between
tasks at intervals (typically when a network connection blocks).
This points to the list of operations which have been generated by the task.
This is the key structure for the DSA Engine.

\item
There is an Operation structure, associated with each pending operation.
These structures are in mesh structure, arranged both by Task and Connection.
\end {itemize}

Multi-level priorities are associated with tasks and operations, which are
used by both engines to control scheduling.
This will be done in QUIPU 6.0 on two bases:

\begin {itemize}
\item  The user specified priority

\item The progress of the operation (long searches are downgraded in
priority).
\end {itemize}


\subsection {Disk Structures}

All of
the data for a given QUIPU DSA 
will be
contained under a single (UNIX) directory.  There will be a directory for
each RDN, where the DSA in question has an Entry Data Block (which may be
master, slave, or cached as described in Section~\ref{disk-cache}).
The name of directory being that of the QUIPU text encoded RDN.
Thus there will be a UNIX directory structure which corresponds to the
portion of the DIT held in the DSA.
There will be file in each RDN directory called ``EDB'', which has the
authoritative version of the data, and one called ``EDB.bak'', which has the
previous version.
This might be extended to provide more comprehensive backup.


When the system is booted, the following will occur:

\begin {enumerate}
\item 
Read tailoring information.
\item 
Look for sequence of Entry Data Blocks implied by the DSAs name.
These will usually be cached. for later reuse.
If not, the default addresses must be used.
\item 
With the DSA's own info available, read in the other master and slave Entry
Data Blocks.
\item 
Read in other Entry Data Blocks, checking for consistency.
\end {enumerate}

\subsection {BNF}

The text formats are all described in BNF.  This part of the design is given
in Volume~5 of the User's Manual \cite{QUIPU.Manual}.

\subsection {Procedural interface}

There is a full procedural access to the Directory Service, and associated
routines to manipulate structures.  This is defined in Volume~5 of the User's Manual
\cite{QUIPU.Manual}.

\section {OSI Choices}

ROS (1988) and the implied protocols (ACSE and Presentation) will be used.
Other combinations (e.g., TP0 over TCP or TP4 over CLNS may be used by
bilateral agreement between DUA and DSA or DSA and DSA).

To ensure full connectivity of the QUIPU Directory Service, one of the
following conditions must be met:

\begin {enumerate}
\item Support of transport class 0 over international X.25(80) (This condition
will be changed to support of CONS with access to the international X.25
subnetwork, when such a statement is realistic).

\item Access to a DSA which will perform application relaying in line with
the procedures of Section~\ref {tcp-only}.
This will need a bilateral agreement.  It is hoped to establish ``well
known'' DSAs which can serve this function for the following well known
networks:
\begin {itemize}
\item  Janet
\item  The DARPA/NSF Internet
\end {itemize}
\end {enumerate}