Annotation of 43BSDReno/contrib/isode-beta/doc/quipu/implementation.tex, revision 1.1

1.1     ! root        1: 
        !             2: \chapter {Implementation Choices}
        !             3: 
        !             4: \section {DSA Structure}
        !             5: 
        !             6: Whilst the operation of a QUIPU DSA is fast, its
        !             7: startup procedure is not, due to reading all of its data from a text file on
        !             8: disk.
        !             9: This long startup means that applications must be able to use
        !            10: multiple DSAs, to prevent lockout whilst the local DSA starts up.
        !            11: Also, the process structure of DSAs must be static.
        !            12: To provide a system with reasonable availability, particularly in view of
        !            13: the system's ability to perform extravagant searching, the basic
        !            14: DSA must be able to handle multiple calls.
        !            15: For this reason, apart from conformance issues, the DSA will be inherently
        !            16: asynchronous, and will need to have its own internal scheduling.
        !            17: Initially, this can be simple minded.
        !            18: However, we are providing a framework for a system which is very
        !            19: sophisticated in this area.
        !            20: 
        !            21: The basic approach of the DSA is to have two (conceptually) co-routined modules, which are
        !            22: interfaced by in-core C structures.
        !            23: The first module is the DSA engine, which resolves inbound queries either
        !            24: by looking them up in its in-core data structures or by generating further
        !            25: queries.
        !            26: The second module is the protocol engine.
        !            27: This is responsible for opening and closing calls, and for mapping between
        !            28: OPDUs on the network and C structures to be handled by the DSA engine.
        !            29: The interface provided to the DSA is largely independent of DAP vs DSP.
        !            30: 
        !            31: \subsection {Memory Structures}
        !            32: 
        !            33: There are a number of structures which are of particular importance.
        !            34: They are summarised here:
        !            35: 
        !            36: \begin {itemize}
        !            37: \item
        !            38: The Entry is as the basic component of the in-core tree, which is linked
        !            39: upwards and downwards between parents and children.
        !            40: The tree always starts at the root, even if there is no information beyond
        !            41: the RDN present.
        !            42: Where an entry corresponds to the base of an Entry Data Block, the parameters
        !            43: of the Entry Data Block are present.
        !            44: Siblings are linked in a chain.
        !            45: Each entry is represented by a `C' structure, which contains:
        !            46: 
        !            47: \begin {itemize}
        !            48: \item
        !            49: Information on the linkage (hierarchical, and between siblings).
        !            50: 
        !            51: \item
        !            52: How Entry Data Blocks are managed.
        !            53: 
        !            54: \item
        !            55: How the ``special'' attributes (ACL, Schema, Alias, Password, DSA location
        !            56: info) are held.
        !            57: \end {itemize}
        !            58: 
        !            59: \item
        !            60: There is a structure associated with each connection.
        !            61: This is used to represent actual and desired connections.
        !            62: These structures are linked into a list, and are the key point for the
        !            63: protocol module.
        !            64: They indicate a list of operations and tasks associated with each connection.
        !            65: When the DSA engine needs a connection, it will see if one is already
        !            66: open to the DSA in question.  If it is not, a connection structure will be
        !            67: created, which the protocol engine will act on in due course.
        !            68: Similarly, the protocol engine will close down unneeded connections, possibly
        !            69: after some (intentional) delay.
        !            70: 
        !            71: \item
        !            72: There is a Task structure associated with each query which arrives.
        !            73: This holds the {\em full} state of the task, so the the DSA can switch between
        !            74: tasks at intervals (typically when a network connection blocks).
        !            75: This points to the list of operations which have been generated by the task.
        !            76: This is the key structure for the DSA Engine.
        !            77: 
        !            78: \item
        !            79: There is an Operation structure, associated with each pending operation.
        !            80: These structures are in mesh structure, arranged both by Task and Connection.
        !            81: \end {itemize}
        !            82: 
        !            83: Multi-level priorities are associated with tasks and operations, which are
        !            84: used by both engines to control scheduling.
        !            85: This will be done in QUIPU 6.0 on two bases:
        !            86: 
        !            87: \begin {itemize}
        !            88: \item  The user specified priority
        !            89: 
        !            90: \item The progress of the operation (long searches are downgraded in
        !            91: priority).
        !            92: \end {itemize}
        !            93: 
        !            94: 
        !            95: \subsection {Disk Structures}
        !            96: 
        !            97: All of
        !            98: the data for a given QUIPU DSA 
        !            99: will be
        !           100: contained under a single (UNIX) directory.  There will be a directory for
        !           101: each RDN, where the DSA in question has an Entry Data Block (which may be
        !           102: master, slave, or cached as described in Section~\ref{disk-cache}).
        !           103: The name of directory being that of the QUIPU text encoded RDN.
        !           104: Thus there will be a UNIX directory structure which corresponds to the
        !           105: portion of the DIT held in the DSA.
        !           106: There will be file in each RDN directory called ``EDB'', which has the
        !           107: authoritative version of the data, and one called ``EDB.bak'', which has the
        !           108: previous version.
        !           109: This might be extended to provide more comprehensive backup.
        !           110: 
        !           111: 
        !           112: When the system is booted, the following will occur:
        !           113: 
        !           114: \begin {enumerate}
        !           115: \item 
        !           116: Read tailoring information.
        !           117: \item 
        !           118: Look for sequence of Entry Data Blocks implied by the DSAs name.
        !           119: These will usually be cached. for later reuse.
        !           120: If not, the default addresses must be used.
        !           121: \item 
        !           122: With the DSA's own info available, read in the other master and slave Entry
        !           123: Data Blocks.
        !           124: \item 
        !           125: Read in other Entry Data Blocks, checking for consistency.
        !           126: \end {enumerate}
        !           127: 
        !           128: \subsection {BNF}
        !           129: 
        !           130: The text formats are all described in BNF.  This part of the design is given
        !           131: in Volume~5 of the User's Manual \cite{QUIPU.Manual}.
        !           132: 
        !           133: \subsection {Procedural interface}
        !           134: 
        !           135: There is a full procedural access to the Directory Service, and associated
        !           136: routines to manipulate structures.  This is defined in Volume~5 of the User's Manual
        !           137: \cite{QUIPU.Manual}.
        !           138: 
        !           139: \section {OSI Choices}
        !           140: 
        !           141: ROS (1988) and the implied protocols (ACSE and Presentation) will be used.
        !           142: Other combinations (e.g., TP0 over TCP or TP4 over CLNS may be used by
        !           143: bilateral agreement between DUA and DSA or DSA and DSA).
        !           144: 
        !           145: To ensure full connectivity of the QUIPU Directory Service, one of the
        !           146: following conditions must be met:
        !           147: 
        !           148: \begin {enumerate}
        !           149: \item Support of transport class 0 over international X.25(80) (This condition
        !           150: will be changed to support of CONS with access to the international X.25
        !           151: subnetwork, when such a statement is realistic).
        !           152: 
        !           153: \item Access to a DSA which will perform application relaying in line with
        !           154: the procedures of Section~\ref {tcp-only}.
        !           155: This will need a bilateral agreement.  It is hoped to establish ``well
        !           156: known'' DSAs which can serve this function for the following well known
        !           157: networks:
        !           158: \begin {itemize}
        !           159: \item  Janet
        !           160: \item  The DARPA/NSF Internet
        !           161: \end {itemize}
        !           162: \end {enumerate}
        !           163: 
        !           164: 
        !           165: 

unix.superglobalmegacorp.com

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.