architecture.tex.svn-base

在Diameter3588协议的基础上开发的软件

to a session. This involves enqueuing the message to the job queue of
that session. Again, a new thread pool job request is created and
injected into the thread pool job request queue. Once dequeued by the
next available thread, the job performs all necessary update to the
session state machine based on the outgoing message if necessary and
then enqueues the message to the job queue of the peer thread where this
message is destined for. The job queues for the peer threads, also known
as transmit queue as shown in Figure~\ref{fig:architecture} is the
logical boundary between the session manager and the transport manager
on the egress path. This same job determines which transmit queue the
message is to be injected to by querying the transport manager peer
table. Once enqueued into the transmitt queue of the peer thread, the
peer thread can compose the message into a raw buffer and transmit it
via it's established connection.

Internally, each peer thread has an internal pending message queue in
addition to it's transmitt queue. The pending message queue shown in
Figure~\ref{fig:architecture}, is where all transmitted but
un-acknowledge messages are stored, i.e. transmitted request messages
that is still awaiting a correspoding answer message. As specified in
Section 5.5.4 of the Diameter draft \cite{basep}, this is used in
failover procedure. Since each peer connection resides within it's own
thread context, detection of transport failure with the remote peer and
immediate failover is done internally within the thread. Failover is
easily accomplised simply by flaging and transferring all the messages
in the pending message queue into the transmitt queue of the peer thread
of an alternative server. However, the architecture dictates that once a
transport connection for a peer thread closes or fails, the peer thread
has to exit. This means that in order to perform failback, the peer
thread schedules a connection retry with the factory request before the
peer thread exits. The scheduling is done via timer request. Once the
timer event occurs, a connection attempt is made by the factory. Once a
connection is re-established with the peer, a new peer thread is started
by the factory and communication with the remote peer is once again
possible. If the re-connection attempt fails, another connection retry
is scheduled and the process is repeated.

\subsection{Message Parsing\label{sec:msgparsing}}

Diameter message parsing can occur at least in the following cases.

\begin{itemize}
 \item When a Diameter message is received from a peer, the transport
 manager needs to parse the message in order to determine whether the
 message should be queued in the message parsing queue for further
 processing by the session manager or forwarded to another Diameter
 node.  In this case, only specific AVPs such as Destination-Host AVP
 and Destination-Realm AVP need to be parsed instead of fully parsing
 against the command dictionary.
 \item When a received Diameter message is processed by the session
 manager, the message is fully parsed against the dictionary by the
 session manager and passed to an appropriate application message
 subscription handler for application specific processing.
 \item When a Diameter message is generated by the application via an
 application subscription handler or by the transport manager, the
 message needs to be constructed by using the message parser module.  In
 this case, the message is fully parsed against the dictionary and
 passed to the transport module.
 \item When a Diameter message generated by the application is sent to a
 peer, the message needs to be parsed by the transport manager in order
 to determine the peer to send the message.  In this case, only specific
 AVPs such as Destination-Host AVP and Destination-Realm AVP need to
 be parsed.
\end{itemize}

For all of above cases, the same date structures are used regardless of
whether parsing is performed for message assemble or disassemble.  The
data structures used for message parsing are container list ({\tt
AAAAvpContainerList}), container\\ ({\tt AAAAvpContainer}) and container
entry ({\tt AAAAvpContainerEntry}).  An example pointer chains of those
data structures are shown in Figure~\ref{fig:parser}.

When assembling or disassembling a message, a container is assigned for
each type of AVP and attached to a container list.  Also, a distinct
container entry is assigned for each AVP that is included (when
disassembling) or to be included (when assembling) in the message and
attached to the container of the corresponding AVP type.  The parent
container list needs to be provided by the application.  When
disassembling a message, either the application or the parser module has
the responsibility of assignment and attachment of containers, but only
the parser module has the responsibility of assignment and attachment of
container entries.  On the other hand, when assembling a message,
applications have the responsibility of assignment and attachment of
containers and container entries.  In any cases, application is the only
entity that have the responsibility of releasing and detaching
containers and container entries.

Assignment and release of containers and container entries is done via
container manager ({\tt AAAAvpContainerManager}) and container entry
manager\\ ({\tt AAAAvpContainerEntryManager}), respectively.  Resource
management for containers and container entries is based on
pre-allocation (instead of on-demand allocation via malloc() system
call) in order to avoid frequent memory allocation/deallocation.

AVP data in a Grouped AVP is stored in a distinct container list for
which a pointer is stored in the container entry for the Grouped AVP.
In other words, a Diameter message payload and a Grouped AVP is treated
in the same manner.  It is also possible to process nested Grouped AVPs
in which a Grouped AVP contains another Grouped AVP as its element AVP.

The Open Diameter thread architecture is designed such that a message is
always exclusively processed by a single thread.  Resource access
contention among multiple threads for message parsing is only possible
when assigning and releasing containers and container entries.  To
eliminate the contention, mutex protection is provided inside the
container and container entry managers.  Thus, applications are not
required to provide their own mutex protection mechanism for message
parsing.

\begin{figure}[htbp]
\center{
\leavevmode
\includegraphics[scale=0.8]{figs/parser_structure.eps}
\caption{Diameter Message Payload Parsing Structure\label{fig:parser}}
}
\end{figure}

Open Diameter defines a template parser class named {\tt AAAParser}
which provides a unified way to parse any data structure.  Any {\tt
AAAParser} class object consists of the following members.

\begin{description}
 \item[Raw data] less-structured data such as string buffers.
 \item[Application data] structured representation of raw data, such as
	    AVP container list.
 \item[Dictionary data] Data that describes a rule for data conversion
 between raw data and application data.  Dictionary data can be null.
 \item[Data set/get functions] A set of functions used for
 setting/getting raw data, application data and dictionary data to/from
 the parser.
 \item[Message parsing and data conversion functions] A pair of
 functions used for data parsing and conversion between raw data and
 application data.
\end{description}

In fact, a number of parser classes are defined for parsing different
objects including Diameter header, Diameter payload, AVP header and AVP
payload of each data type, by specializing the template {\tt AAAParser}
class.

\subsubsection{Registering New AVP Types\label{sec:avpparsing}}

Open Diameter parser library defines an API to define a new AVP type and
a parser to parse the new type, in addition to the default supported AVP
types such as Integer32, Unsigned32, OctetString, UTF8String, Grouped
and IPAddress.  This feature is particularly important not only for
developing new Diameter applications and but also for developing a new
protocol that uses Diameter AVP formats.  PANA (Protocol for carrying
Authentication for Network Access) is an example of the latter case.

Registration of a new AVP type can be done via adding a new AVP type
entry called {\tt AvpType}, where an AVP type entry consists of the
following members.

\begin{description}
 \item[Type name] the name of this AVP type.
 \item[Type code] an integer that is used by the parser library for
 distinguishing this AVP type.  The type code must be unique among all
 the types in the system.  The type code is used only inside the library
 and never carried in Diameter messages.
 \item[Type size] the minimum size of the data of this AVP type.  This
 information is used for creating an placeholder AVP when a certain
 class of error occurs.
 \item[Dictionary data] data that describes a rule for data conversion
 between raw data and application data.  Dictionary data can be null.
 \item[Parser creator] a function object or a functor that is used for
 creating a parser class instance that parses the data of the AVP type.
 \item[Container entry creator] a function object or a functor that is
 used for creating a container entry that contains the data of the AVP
 type.
\end{description}

The list of {\tt AVPType} instances are retained in an AVP type list
{\tt AAAAvpTypeList}, which is a singleton.


\subsection{Configuration\label{sec:configuration}}

All configuration files for the Open Diameter library, as with the
parser library, are stored in XML format. The root configuration file,
configuration.xml, contains references to other configuration files
which are also in XML format such as the peer and routing databases. As
with the message parser library, the Open Diameter library uses the
Xerces C++ XML library to parse the local configuration files. Most
entries in the configuration files directly reflects the parameter
stated in the Diameter draft \cite{basep} and are self explanatory.

\begin{thebibliography}{Bibliography}
\bibitem[ACE]{ace}Douglas C. Schmidt, ``The ADAPTIVE Communications
Environment, An Object-Oriented Network Programming Toolkit for
Developing Communications Software,'' June 1993.
\bibitem[BASE-P]{basep}P. Calhoun, et al., ``Diameter Base Protocol,''
Internet-Draft, Work in Progress, December 2002.
\bibitem[API]{api} Y. Ohba and V. Fajordo ``Diameter C++ API'',
http://www.opendiameter.org/.
\end{thebibliography}

\end{document}