\subsection{Prototype}
\label{s:prototype}
In Figures~\ref{f:prototype} and~\ref{f:controller_overviews} (a), we illustrate the architecture of a \floodlight controller before (~\ref{f:controller_overviews} (a)) and after (~\ref{f:prototype}) our modifications.  We note that the key components of our prototype are: \stub,\loader, \criu, \proxy. The \stub, \loader and \proxy together allow us to isolate applications and together make up the AppVisor.  The error detection and recovery code lies within the \proxy, which uses CRIU~\cite{criu} checkpointing for cloning.  An application crash is detected through the failure of the connection between the \stub and the \proxy. 

\begin{figure}
	\begin{center}
		%\noindent \hrulefill 
		\epsfig{file=figs/SafeFloodlightPrototype.eps,height=2in} 
		\caption{Prototype Implementation of \name}
		\label{f:prototype}
	\end{center}
	\end{figure}
	
	
Our current prototype lacks a NetLog. Instead we buffer messages from the Application to the network, in the \proxy, and only release them when the \stub sends a special message indicating that the application has completed event processing.  We confess that while this approach is feasibility it is not ideal for two reasons: 1.) the buffering of messages could result in Application deadlock. and 2.) buffering will result in a flood of message between the controller and the switches. Prior work~\cite{devoflow:sigcomm11} has shown that batching messages to a switch can overwhelm the switch CPU and deteriorate the network performance.  Thus in future implementations we intend to replace the buffer with an appropriate implementation of NetLog.

Next, we describe the implementation of each component:


\begin{itemize}
	\item {\loader:} This starts the \floodlight applications, each in a separate JVM with the \stub. To minimize the size of the JVM, the \loader loads only the minimal set of Java classes into the JVM.
	\item {CRIU:} Currently, we leverage CRIU which uses {\it /proc/} to capture process information and store it to file. We've altered CRIU to store the process information in memory. Thus speeding up the action of cloning an application, AKA backing-up, and of reverting to a clone, AKA rolling-back, in the event of failure.
	
	
	\item {\stub:} Currently, this implements key controller interfaces and intercepts calls from the application, serializes the calls, and transfer them to the \proxy within the controller JVM. In the reverse, it accepts controller events from the \proxy and deserializes them and call the appropriate application functions.  For example, traditionally for a packet-in event \floodlight calls an applications {\it receive} method. However, now the \floodlight calls the \proxy's {\it receive} method, the \proxy serializes and sends it over to the \stub which then deserializes and in turn call's the application's {\it receive} method.
	
	In addition, the \stub alerts the \proxy when event-processing is complete: we identify the boundary of event processing as the end/return of the application's event-handler. For example, when the application's {\it receive} method returns.

 	\item {\proxy:} As the heart of our prototype, this implements the set of interfaces that the application implements and it similarly registers for the events that the application registers for (this information is passed to the \proxy by the \stub.)  Similar to the \stub, the proxy uses \netty for communication and it serializes/de-serializes messages sent over \netty. Unsurprisingly, the \proxy performs the reverse of the \stub.

Prior to sending an event, from either the network or a service, to the \stub, the \proxy uses the \criu to clone the application's JVM.  Should the \proxy detect a failure, via a \stub disconnect, it rolls back to the last checkpoint. At most, one clone needs to be maintained per-application and this clone can be deleted when the \stub indicates successful event process. 
	
\end{itemize}
