|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: T n
Length: 3818 (0xeea) Types: TextFile Names: »nameservice.tex«
└─⟦2d1937cfd⟧ Bits:30007241 EUUGD22: P.P 5.0 └─⟦35176feda⟧ »EurOpenD22/isode/isode-6.tar.Z« └─⟦de7628f85⟧ └─⟦this⟧ »isode-6.0/doc/manual/nameservice.tex«
\chapter {The QUIPU Nameservice} \label {ns_design} \section {Requirements} Many applications make a relatively simple use of the directory, with the following type of requirements: \begin{itemize} \item Reading a single (or small number of) attribute(s). \item Public data only (i.e., no need for access control) \item Most data accessed is available locally \end{itemize} A typical usage is to look up and Application Entity Title to determine a presentation address. The DAP is a rather heavyweight procedure to achieve this. This chapter describes a lightweight mechanism to access a {\em local} DSA. The protocol was designed by Marshall Rose. \section {Design} The QUIPU Name Server uses a lightweight interface to the QUIPU Directory Service. This gives an application the ability to supply a distinguished name, and the Attribute Type required, in IA5String format (because the encoding is more efficient). The name server will then use the lightweight protocol to pass a ``read'' operation onto the directory. The Directory will then perform a lookup of this data (giving the operation a high priority status), and return the value. The nameservice protocol is straight-forward. The initiator formats a query message for the nameservice. This message is sent via a connectionless protocol ``n'' times. Each time after sending the message, the initiator waits up to ``s'' seconds for a response. If the response arrives, the initiator processes it; otherwise, the initiator either sends another message or gives up. A definition of the PDUs for a ``query'' and the ``response'' to that query are shown in Figure~\ref{ns-h}. \tagrind {ns}{Name Service Protocol}{ns-h} The request-id identifies this particular Query; the same value is used in the message, regardless of how many times the message is sent. The name identifies the DN being looked-up. It is a string from the IA5 repertoire which expresses the DN in the QUIPU format. The attribute identifies the desired attribute of the DN. It is a string from the IA5 repertoire which expresses the attribute as known in it's user-friendly form. The cache-ok tells the nameservice if it is permitted to use cached information when responding to the query. When the nameservice receives a Query, it processes it as follows: \begin{enumerate} \item It constructs an environment to process the Query with access rights for publically-readable information. \item It prepares a Response using the request-id from the Query. \item It reads the indicated DN and attribute from the DIT. If the DN exists with the given attribute, it returns the value of that attribute. In the event that multiple values are present, the nameservice returns any one of those values. The ASN.1 encoded distinguished name is also returned, typically for use as the Application Entity Title. \item It then sends the response to the initiator. \end{enumerate} A message called the ``Response'' is returned by the name server (see Figure~\ref{ns-h}). request-id corresponds to the Query which invoked the nameservice. value is the answer to the Query. It is present only if no errors occurred during processing. The transaction protocol used by the nameservice is very simple: Response messages are not cached and there are no Keep-alive nor In-Progress messages. \section {Support} This protocol can optionally be supported by a QUIPU DSA. A simple procedural interface (DUA) s supplied which is used by ISODE applications such as FTAM and IMISC to look up Presentation addresses of remote Application Processes. The interface is designed so that use of the lightweight protocol or DAP can be chosen at compile time (the saving in code size is significant, and so this is not a runtime choice). This is described in the QUIPU Manual.