Return to update.tex CVS log

Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / quipu

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

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.