![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to update.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 update.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / quipu |
1.1 root 1: \chapter {Replicating Updates}
2: \label {des-first}
3: \label {dist-update}
4:
5:
6: \section {Basic Update Approach}
7: \label {edb-ros}
8:
9: QUIPU 5.0 supports a simple automatic update
10: mechanism.
11: This allows for copying of Entry Data Blocks,
12: but with a simple check to ensure that only new information is copied.
13: Slave copies are obtained by use of a new remote operation.
14: The argument to the operation is the name of the Entry, and the
15: version number of the copy of the Entry Data Block held
16: locally.
17: A FULL copy of the Entry Data Block is returned if this version
18: is out of date.
19: In the DSA's entry, there is a list of Entry Data Blocks for which the DSA
20: has master or slave copies, and the DSA which it gets updates from.
21: For each Entry Data Block, there is the list of DSAs which pull the Entry
22: Data Block, and for slave copies, which DSA the update should come from.
23: It is assumed that this operation will be invoked sufficiently
24: often for it to be acceptable to consider the slave data as
25: ``official''.
26: For the type of usage being considered, this probably means several
27: times per day.
28: Within QUIPU, this operation will be added to a new protocol, which will
29: also contain the DSP ASEs \footnote{In QUIPU 5.0, getEDB is implemented
30: withing the DAP.}.
31: The operation is specified in Figure~\ref{getedb-py}.
32:
33: \tagrind {getedb}{EDB Access Operation}{getedb-py}
34: \clearpage
35:
36: Note that a DSA receiving a GetEDB operation, should check the associated
37: EDBInfo, to ensure that the DSA in question is allowed to pull a copy of
38: this EDB.
39:
40: The operation may be used to determine which version of the EDB is currently
41: master. This might be used when a query with dontUseCopy arrives, in order
42: to determine whether slave information is accurate. This would be a big
43: performance win for search and list operations, due to potnetila reduction
44: in information transferred.
45:
46: \section {Reliable ROS}
47:
48: This mechanism will be implemented in QUIPU 6.0.
49:
50:
51: Before we can explain the more sophisticated update approach, a new service
52: is described. This is
53: {\em Reliable ROS}
54: Reliable ROS has the following characteristics.
55:
56: \begin {itemize}
57: \item The operation should be expected to succeed (errors will require human
58: intervention, and so must be rare)
59: \item The operation may be applied to many systems (multicast)
60: \end {itemize}
61:
62: The argument is defined in Figure~\ref{reliableros-py}
63:
64: \tagrind [hb]{reliableros}{Reliable ROS}{reliableros-py}
65:
66: This argument identifies a ROS operation argument.
67:
68: Reliable ROS is only applicable to operations where the result is not in
69: doubt.
70: An operation is applied, and the result discarded.
71: Any error is assumed to be catastrophic, and should be flagged as an
72: operator error.
73:
74: In the QUIPU Directory, Reliable ROS operations will be applied to one or
75: more Entry Data Blocks, and the list is made explicit.
76: If one or more of the version numbers is wrong, the update is assumed to
77: have arrived out of sequence.
78: It will therefore be backed off for a temporary period, so that it can
79: be applied later when the missing update has been applied.
80: After a certain period, catastrophic loss can be assumed, and operator
81: intervention summoned.
82:
83: Reliable ROS is a multicast service.
84: Thus it may be used to apply updates to multiple DSAs.
85: This is achieved by basing it over the X.400 (1984 or 1988) P1 service
86: \cite{CCITT.MHS.84} \cite{CCITT.X411.84}.
87: Every DSA has an associated O/R address, which is naturally managed by
88: the QUIPU directory service.
89: Local delivery complying to the previous paragraph must be supported.
90: This goes beyond the basic X.400 services, as it implies UA ability to
91: perform temporary rejects on the basis of content.
92: This is straightforward to provide for a co-resident UA.
93: Atomic submission of multiple updates is achieved in a straightforward
94: manner, as this is a basic X.400 service.
95:
96: This approach may seem a little strange at first sight.
97: However, building a reliable spooling system needed for update is a
98: non-trivial exercise.
99: It is preferable to utilise other exising systems which can
100: already provide this service.
101: Modularity is one of the major benefits of OSI.
102:
103: \section {Incremental Update}
104:
105: This aspect will be implemented in QUIPU 6.0.
106:
107: The QUIPU update mechanism is fully general, except that modifyRDN cannot
108: be applied to non-leaf entries. This is because of the difficulty with
109: controlling references in other DSAs.
110: That is, all the the OSI Directory restrictions, except the one mentioned, are
111: lifted.
112: To achieve the effect of modifyRDN, the new tree must be created (as a copy of the
113: old one), and then the old one deleted.
114: The modfyRDN restriction means that all updates apply to a single Entry Data
115: Block.
116:
117: In basic terms, the update operation is now straightforward. Navigation to
118: the correct DSA occurs as for the QUIPU Name Service. The only distinction
119: is that the Master DSA must be selected, rather than picking a convenient
120: copy. The Master DSA will hold a copy of the Entry Data Block in memory.
121: The validity of the update in terms of the Directory Standards and Access
122: Control can be checked. The DSA will then use Reliable ROS to submit this
123: update to all of the entries which access it by GetEntryDataBlock. That is,
124: the same distribution hierarchy is used for both forms of update. Each
125: update will include the DSA generating the update (i.e. itself), and thus
126: avoid the problems of immediate disk synchronisation.
127: The Message Handling System deals with the reliable multicast.
128:
129: \section {Subtree Update}
130:
131: Currently, all EDBs must be dealt with explictly. It seems useful to extend
132: the current model to allow propogation of full subtrees. This is
133: particularly true where an EDB has a relatively small child EDB.
134: This will be added in QUIPU 6.0.
135:
136: \section {Spot Shadowing}
137:
138: This mechanism will be implemented in QUIPU 6.0.
139:
140: The basic QUIPU model assumes that sibling entries are held together. This
141: has been extended to allow for cross references and subordinate references.
142: These will lead to skeleton entries, which are pointers to other DSAs (which
143: will not be QUIPU). It seems desirable to automatically pull copies of such
144: entries in order to giver reasonable performance for searching. The
145: mechanism of ``spot shadowing'' will be used. As there is no mechanism for
146: supporting this properly, copies of the entry will simply be read across at
147: reasonable intervals. This is likely to be needed only for the first two
148: levels of the tree. Note that only one QUIPU DSA need perform this for a
149: given spot shadow. This can then be propagated to other QUIPU DSAs using
150: the superior private mechanisms.
151:
152: This approach can also be viewed as a system maintained cache.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.