|
|
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:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.