![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to implementation.tex CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / quipu|
Return to implementation.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / quipu |
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.