libxipc_overview.tex

xorp源码hg

%
% $XORP: xorp/docs/libxipc/libxipc_overview.tex,v 1.19 2007/03/15 00:43:13 pavlin Exp $
%

\documentclass[11pt]{article}

%\usepackage[dvips]{changebar}

\usepackage{subfigure}
\usepackage{fullpage}
\usepackage{setspace}
\usepackage{times}
\usepackage{latexsym}
\usepackage{epsfig}
\usepackage{graphicx}
\usepackage{xspace}
\usepackage{color}
\usepackage{amsmath}
\usepackage{rotating}
\usepackage{moreverb}
\usepackage{listings}
\usepackage{alltt}
\usepackage{stmaryrd}
%\usepackage[dvipdf]{graphics}
%\usepackage[dvips]{graphicx}
%\usepackage{xorp}

\definecolor{gray}{rgb}{0.5,0.5,0.5}
\newcommand{\etc}{\emph{etc.}\xspace}
\newcommand{\ie}{\emph{i.e.,}\xspace}
\newcommand{\eg}{\emph{e.g.,}\xspace}
%\newcommand{\comment}[1]{{\color{gray}[\textsf{#1}]}}
%\newcommand{\comment}[1]{}

% Changebar stuff
% \newenvironment{colorcode}{\color{blue}}{}
% \renewcommand{\cbstart}{\begin{colorcode}}
% \renewcommand{\cbend}{\end{colorcode}}

% \pagestyle{empty}

\begin{document}

\title{XORP Inter-Process Communication Library Overview \\
\vspace{1ex}
Version 1.4}
\author{ XORP Project					\\
	 International Computer Science Institute	\\
	 Berkeley, CA 94704, USA			\\
         {\it http://www.xorp.org/}			\\
	 {\it [e-mail]}
}
\date{March 20, 2007}

\maketitle


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{abstract}

Extensibility and robustness are key goals of the eXtensible Open
Router Project (XORP).  A step towards satisfying both of these goals
is to separate the functional components of a router into independent
tasks and to execute each of these tasks as separate processes.  From
an extensibility perspective this allows components of the router to
be started, stopped, and exchanged dynamically, and to be distributed
across a number of hosts.  From a robusness perspective, the processes
are afforded the protection mechanisms afforded by modern operating
systems so a failure of one routing task does not necessarily bring
the router to a halt. The routing tasks do need to communicate and we
have developed an asynchronous remote procedure call mechanism that is
capable of working with multiple transport protocols between remote
hosts and can leverage existing IPC mechanisms within a single
host. This document discusses aspects of the design and the directions
it may take in future.

\end{abstract}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introduction}

Robustness and extensibility are two of the goals of the XORP project.
One way a router can achieve robustness is to run routing protocols in
protected environments, such as separate userland processes on a
modern operating system.  And one way a router can achieve
extensibility is to be independent of the details about where those
routing processes are running and what the composition of the
forwarding plane is.  The routing processes and network interfaces
could be running on one machine or distributed across a cluster of
machines that appear as single router.  A necessary feature once
routing protocols are running in distinct processes and potentially on
distinct machines is an inter-process communication mechanism.  In
contrast to traditional inter-process communication schemes, the
scheme employed in the XORP project can utilize multiple transport
protocols and potentially communicate with unmodified components
through these protocols, for instance SNMP or HTTP.

The lofty goals of XORP's Inter-Process Communication (XIPC) scheme are:

\begin{itemize}

  \item to provide all of the IPC communication mechanisms that a router is
  likely to need, \eg sockets, ioctl's, System V messages, shared memory.

  \item to provide a consistent and transparent interface irrespective
  of the underlying transport mechanism used.

  \item to transparently select the appropriate IPC mechanism when
  alternatives exist.

  \item to provide an asynchronous interface.

  \item to be efficient.

  \item to potentially wrapper communication with non-XORP processes,
  \eg HTTP and SNMP servers.

  \item to be renderable in human readable form so XORP processes can
  read and write commands from configuration files.

\end{itemize}

The XIPC goals are realized through XORP Resource Locators (XRLs) and
the XORP IPC (XIPC) library.  XRLs are responsible for describing an
inter-process calls and their arguments.  An XRL may be represented in
human readable form that allows for easy manipulation with editing
tools and invocation from the command line during development.

XORP processes export XRL interfaces to a process known as the {\em
Finder} and inform it of which IPC schemes are available to invoke
each XRL.  The Finder is then able to provide a resolution service for
XORP processes.  When a process needs to dispatch an XRL it first
contacts the Finder, obtains details on which IPC mechanisms are
available to contact the process, and then instantiates
a suitable transport.

The XIPC library provides the framework for handling and manipulating
XRLs, communicating with the Finder, and common protocol families for
conducting IPC.  In addition to the XIPC library, an interface
definition language exists, together with tools to translate these
into callable C++ interfaces and into a set of C++ handler routines
for handling the receipt of XRL calls.  These tools are described in
document \cite{xorp:xrl_interfaces}.  The tools reduce the amount of
familiarity the working programmer needs to have with the internals of
the XIPC library.  This document provides an overview of the XIPC
library and is the recommended starting point before using the
library.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{XORP Resource Locators (XRL's)}

The mechanism we've settled on for IPC within XORP processes is mediated
through \emph{Xorp Resource Locators} (XRL's).  An XRL describes a
procedure call.  It comprises the protocol family to be used for
transport, the arguments for the protocol family, the interface of the
target being called and its version, the method, and an argument
list.  Examples of XRLs in their human readable forms are shown in
figure \ref{fig:human-readable}.  The existence of a human readable
form for XRLs is chiefly a convenience for humans who need to work
with XRLs and not indicative of how they work internally.

Resolved and unresolved forms of the same are XRL are depicted in
figure \ref{fig:human-readable}.  The unresolved form is the starting
point for the majority of inter-process communication.  In the
unresolved form the protocol family is set to ``finder'' and the
protocol parameters set to the target name that the XRL call is
intended for.  A process wishing to dispatch an XRL for the first time
passes the unresolved XRL to the Finder, which returns the resolved
form with the appropriate protocol family and protocol family
arguments.  The finder may also modify the other components of the
XRL, but doesn't usually do so.  This functionality may be useful when
supporting backwards compatibility of interfaces, \ie the Finder could
modify the interface number and method name.

The resolved forms of XRLs are typically maintained in a client side
cache so the Finder need not be consulted for each XRL dispatch.

%%%%%%%%%%%%%%%%%%%%%
\clearpage
\begin{sidewaysfigure}
(a) Unresolved form:

\begin{centering}
\small\begin{verbatim}
finder://fea/fti/0.1/add_route?net:ipv4net=10.0.0.1/8&gateway:ipv4=192.150.187.1
+-----   +-- +-- +-- +-------- +------------------------------------------------
|        |   |   |   |         |
|        |   |   |   Method    Arguments
|        |   |   |
|        |   |   Interface version