libxipc_overview.tex

xorp源码hg

|        |   |
|        |   Interface Name  
|        | 
|        Protocol Parameters
|
Protocol Family
\end{verbatim}
\end{centering}
\normalsize

(b) Resolved form:

\small
\begin{verbatim}
stcp://192.150.1.5:1992/fti/0.1/add_route?net:ipv4net=10.0.0.1&gateway:ipv4=192.150.1.1
+---   +--------------  +-- +-- +-------- +--------------------------------------------
|      |                |   |   |         |
|      |                |   |   Method    Arguments
|      |                |   |
|      |                |   Interface version 
|      |                |
|      |                Interface Name  
|      | 
|      Protocol Parameters
|
Protocol Family
\end{verbatim}
\normalsize
\caption{\label{fig:human-readable}Human readable XRL forms.}
\end{sidewaysfigure}
\clearpage

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{XRL Targets and the Finder}

An {\em XRL Target} is an entity that is capable of dispatching XRLs.
The {\em Finder} is the entity in XIPC system that knows about XRL
Targets and is responsible for directing IPC communication between XRL
Targets.  The IPC communication schemes that XRL Targets use to
communicate XRLs between each other once they have been resolved by
the Finder are known as {\em Protocol Families}.

Each XRL Target has an associated class name and an instance name.
Class names indicate the functionality that the target implements and
there may be multiple targets in the XIPC system with the same class
name.  Instance names are unique identifiers for each target in the
XIPC system.  XRLs to be resolved by the Finder may address a target
by class name or by instance name.  The Finder treats the first
instance in a class as the primary instance of that class and XRLs
directed to a class resolve equivalently to the primary instance.

The class of an XRL Target dictates which methods the target supports.
Interfaces are collections of XRLs that relate to some aspect of
functionality and objects in a given class implement handlers for one
or more interfaces.  Once an XRL Target has registered its presence
with the Finder, it registers the XRLs associated with the interfaces
it supports. XRLs are registered one at a time and only when all of
the XRLs have been registered does the XRL Target become visible to
the outside world through the Finder.

The Finder provides a one-to-many mapping service.  Each XRL Target
may specify multiple protocol families for each XRL they export. When
a target requests the resolution of an XRL, the answer will contain
the complete list of available resolutions and the resolver can decide
which it would prefer to use.  When registering the target indicates
the XRL method name and an appropriate protocol family.  so targets
that support multiple protocol families perform a separate
registration each XRL and protocol family pair.  This provides a
flexible system for implementing optimizations on the level of
individual XRLs.

% When a process starts up, it registers it's XRL targets with the
% Finder, and registers the XRLs supported by each target individually.
% During registration of an XRL, both the method name and the available
% protocol families for executing the XRL are communicated to the
% Finder.  The first XRL Target instantiated in a particular class is
% considered by the Finder to be the primary instance of that class.
% When the Finder receives XRLs to resolve that refer to a class name as
% a target, it resolves them as if the XRL contained the instance name
% of the primary instance in the class.  Should the XRL Target
% corresponding to the primary instance of a class leave the XRL system,
% because of a process exiting or explicit deregistration, then the next
% instance of the class that registered with the Finder is used as the
% primary instance.

There is a slight subtlety with registration for the sake of security.
This arises because some of the protocol families that can be used to
communicate XRLs and responses to XRLs allow for remote access,
examples being UDP and TCP protocol families.  The source code to the
XORP project is publicly available and the XRL interfaces and targets
are included the package.  With knowledge of the XRL interfaces and
targets it would be relatively straightforward for external parties to
opportunistically dispatch XRLs on a XORP router.  However, if XRL
communication can be coerced to use the Finder, access control can be
enforced centrally.  To achieve this, the Finder performs XRL method
name transformation.  When an XRL is registered with the Finder, the
Finder transforms the resolved form of the XRLs method name, and
instructs the registering target to dispatch the transformed name as
if it were the original name.  The method name transformation is
designed to be hard to counter and each XRL method is transformed
uniquely.  The registering process therefore has to maintain a mapping
table from the interface.

In addition to handle XRL registrations and resolutions, the Finder is
capable of notifying XRL Targets about events it is aware of, like the
birth and death of other XRL Targets.  The Finder exposes an XRL
interface for this purpose and is able to invoke XRLs on XRL Targets
to perform the notification.  A special tunneling mechanism exists in
the communication protocol used to communicate with the Finder for
this purpose.  The details of this communication will be expanded upon
later on [XXX in a later edit to this document].

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Components of XRL Framework}

\begin{description}

  \item [XRL] an inter-process call that is transparent to the
  underlying transport method.

  \item [Finder] the process that co-ordinates the resolution of target
  names into a parseable form to find the XRL Protocol Family Listener.

  \item [XRL Router] an object responsible for sending and receiving
  XRLs.  They manage all the underlying interactions and are the
  interface that users are expected to use for XRL interactions.
  % TODO: the above description of [XRL Router] is unclear.

  \item [Finder Client] an object associated with an XRL Router that
  manages the communication with the Finder.

  \item [XRL Protocol Family] a supported transport mechanism for the
  invoked XRL.

  \item [XRL Protocol Family Sender] an entity that dispatches XRL
  requests and handles responses.  Senders are created based on Finder
  lookup's of the appropriate communication mechanism.

  \item [XRL Protocol Family Listener] an entity that listens for
  incoming requests, dispatches the necessary hook, and sends the
  responses.  When Listeners are created they register the appropriate
  mapping with the Finder so that corresponding Senders can be
  instantiated to talk with them.

\end{description}

The kdoc documentation provides details of the particular classes.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%     APPENDIX
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\appendix
\section{Modification History}

\begin{itemize}

  \item December 11, 2002: Initial version 0.1 completed.

  \item March 10, 2003: Minor changes.
  Updated the version to 0.2, and the date.

  \item June 9, 2003: Updated the version to 0.3, and the date.

  \item August 28, 2003: Updated the version to 0.4, and the date.

  \item November 6, 2003: Updated the version to 0.5, and the date.

  \item July 8, 2004: Updated the version to 1.0, and the date.

  \item April 13, 2005: Updated the version to 1.1, and the date.

  \item March 8, 2006: Updated the version to 1.2, and the date.

  \item August 2, 2006: Added ``Modification History'' appendix.
  Updated the version to 1.3, and the date.

  \item March 20, 2007: Updated the version to 1.4, and the date.

\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%     BIBLIOGRAPHY
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\bibliography{../tex/xorp}
\bibliographystyle{plain}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}