%
%  $Id: reactor.tex,v 1.12 2005/04/25 12:45:56 gokhale Exp $
%
\section{Overview of Event Demultiplexing Patterns}
\label{sec:event_patterns}

This section describes the event demultiplexing patterns found in 
real-world systems, such as a virtual private network service that
uses the virtual router concept~\cite{Knight:04}.
Section~\ref{sec:vr} provides an overview of the virtual router to
illustrate the event-driven nature of the service.
Section~\ref{sec:reactor} then presents an outline of the reactor
pattern~\cite{Schmidt:00a} found in many large distributed systems
like the virtual router-based VPN.

\subsection{Description of the VPN Service}
\label{sec:vr}

Figure~\ref{fig:vpn-arch} illustrates the architecture of a
provider-provisioned virtual private network
(PPVPN)~\cite{Nagarajan:04} using a VR. A VR is a
software/\-hardware component that is 
part of a physical router called the provider edge (PE) router. A VR
contains the mechanisms to provide highly scalable, differentiated
levels of services in VPN architectures. Multiple VRs can reside on a
single PE device. VRs can be arranged in a hierarchical fashion within
a single PE as shown in Figure~\ref{fig:vpn-arch}.  Moreover, an entity
acting as a service provider for an end customer might itself be a
customer of a larger service provider. VRs may also use different
backbones to improve reliability or to provide differentiated levels
of service to customers. 

\begin{figure}[!h]
\center{\includegraphics[width=4.5in]{../../proposals/NSF_CyberTrust_VU_UConn05/eps/VPN-VR-arch.eps}}
%\steal{0.2in}
\bfcaption{VPN Architecture using Virtual Routers}
\label{fig:vpn-arch}
\end{figure}

Customer edge (CE) devices (e.g., workstations or handhelds) wishing
to join a VPN connect to a VR on the PE device.  A VR can multiplex
several distinct CEs belonging to the same VPN session.  A VR may use
tunneling mechanisms to use multiple routing protocols and link layer
protocols (e.g., IPSec, GRE, and IP-in-IP) to connect with the CEs.  A
totally different set of protocols and tunneling mechanisms could be
used for inter-VR or VR-backbone communication.  These tunneling
mechanisms can also be the basis for differentiated levels of service,
as well as to provide improved reliability.  A VR also comprises
firewall capabilities. 

The architecture of the VR is aptly suited for event-driven
systems, which requires demultiplexing and dispatching events to
the correct event handler in a VR.  For example, requests to join a
VPN are a type of an event that must be handled by the VR.  Events
indicating arrival of data are yet another type of event that must be
handled by forwarding the data to the correct next hop in the VPN set
up. 

The VR-based VPN illustrates an event-driven system that must be
reliable and that can be designed and implemented using reusable event
demultiplexing and dispatching patterns, such as the reactor.

\subsection{Description of the Reactor Pattern}
\label{sec:reactor}

Figure~\ref{fig:mw-demux} depicts a typical event demultiplexing and
dispatching mechanism documented in the reactor
pattern~\cite{Schmidt:00a}.  The 
application registers an event handler with the event demultiplexer
and delegates to it the responsibility of listening to incoming
events. On the occurrence of an event, the demultiplexer dispatches the
event by making a callback to the correct application-supplied event
handler. This is the idea behind the reactor pattern, which provides
synchronous event demultiplexing and dispatching capabilities.

\begin{figure}[htb]
\begin{center}
\includegraphics[width=2.3in]{../Sigmetrics-2005/eps/demux.eps}
\bfcaption{Event Demultiplexing Pattern}
\label{fig:mw-demux}
\end{center}
\end{figure}

Figure~\ref{fig:reactor_dynamics} illustrates the reactor pattern
dynamics. We categorize these dynamics into two phases described below.

\begin{enumerate}
  \item {\bf Registration phase:} In this phase all the event handlers
  register with the reactor associating themselves with a particular
  event type they are interested in.  Event types usually supported by
  a reactor are input, output, timeout and exceptions.  The reactor
  will maintain a set of handles corresponding to each handler
  registered with it.
  \item {\bf Snapshot phase:} Once the event handlers have completed
  their registration, the main thread of control is passed to the
  reactor, which in turn listens for events to occur. A snapshot is
  then an instance in time wherein a reactor determines all the event
  handles that are enabled at that instant.  For all the event handles
  that are enabled in a given snapshot, the reactor proceeds to
  service each event by invoking the associated event handler.  There
  could be different strategies to handle these events. For example, a reactor
  could handle all the enabled events sequentially in a single thread
  or could hand it over to worker threads in a thread pool. After all
  the events are processed, the reactor proceeds to take the next
  snapshot of the system.
\end{enumerate}

\begin{figure}[htb]
\begin{center}
\includegraphics[width=5in]{eps/reactor_dynamics.eps}
\bfcaption{Reactor Pattern Dynamics}
\label{fig:reactor_dynamics}
\end{center}
\end{figure}

Many different variations of the reactor pattern are possible. These
variations stem from the different event demultiplexing and event
handling strategies used in a reactor.  For example, in
network-centric applications, networking events can
be demultiplexed using operating system calls, such as {\tt select} or
{\tt poll}.  For graphical user interfaces (GUIs), these events could
be due primarily to mouse clicks and can be handled by GUI
frameworks like Qt or Tk. On the other hand, the event handling
mechanisms could involve a single thread of control that demultiplexes
and handles an event, or each event could be handled concurrently using
worker threads in a thread pool or by thread on demand.

In this paper, we have developed a performability model of 
the reactor pattern, which uses the {\tt select} system call for event
demultiplexing and uses a single thread of control to demultiplex and
handle events identified in a given snapshot. In the rest of the paper
we describe this model and demonstrate the use of the model for
performability analysis. 
