% -*- TeX-master: "report.tex" -*-

% System Design
% join, leave, get, put, remove bindings, system diagram, 

InHome is implemented as a peer-to-peer network that operates like a
distributed cache.



\begin{figure}[t]
  \centering
  \includegraphics[scale=0.3]{architecture.ps}
  \caption{InHome system overview. The application running on top of InHome wants to fetch ``cnn.com''. It first requests the data via the InHome system. The request goes through the InHome daemon to other InHome daemons in the network. These return the data or a message saying they do not have the data. Alternatively, the application can directly query the ``cnn.com'' server.}
  \label{fig:architecture}
\end{figure}

\subsection{System Architecture}
Figure \ref{fig:architecture} illustrates the overview of the
system. Web applications or plugins for existing applications run on top of the InHome system. The data is stored in the form of objects identified by
an ID-s. The content of the objects consists of raw bytes. Thus, InHome is application independent because we do not make any
assumption about the content of the data; it can support web
pages, video, music, or other files.

Clients run a background InHome daemon whose tasks are:
\begin{itemize}
\item Maintain the metadata and routing information in the system
  synchronized with the other InHome daemons. This information is used
  to locate objects in the system.
\item Perform web object lookups as requested by the application which runs on top of it.
\item Service content to other InHome daemons that request it. 
\end{itemize}



\subsection{Interface}



InHome exports a simple and general interface which is summarized in
Table \ref{table:interface}.

\begin{table*}
\caption{System Interface}
\label{table:interface}
\centering
\begin{tabular}{|c|p{10cm}|}
\hline
Function & Description \\
\hline \hline
\texttt{join(info, peer)} & Joins the local client the network information in $info$ by contacting a $peer$ that is already in the network. \\
\hline
\texttt{put(name, data)}
& Creates a binding between a $name$ of an object and the data in the object. \\
\hline
\texttt{data = get(name, timeout)}
& Returns the data object corresponding to $name$ or null if not found. \\
\hline
\texttt{remove(name)} & Removes the binding of $name$. \\
\hline
\end{tabular}
\end{table*}

Upon startup, the InHome client needs to join the InHome network. The
$join$ function takes the client's network information (such as IP
address) and the network information of another peer that is known to
be in the network. The easiest way to find another peer is for the
organization to set up a centralized membership tracker. This solution
is not ideal because it violates the third property presented in
Section \ref{sec:Problem}. All other solutions are vastly more
complicated, so the simplicity of the tracker may outweigh any other
considerations. The membership tracker will not be heavily loaded so
any machine will do, even a well known client that does not leave the
network can do the job.

The $get$ and $put$ functions are responsible for placing and reading
data from the system. The $name$ identifies the objects and it can be
a URL, a file name, a video name, etc. The data is stored as a
sequence of bytes and it is not interpreted by InHome clients. Using a
general interface, InHome can support a range of applications from web
pages to videos or other general files.

If the application is interested in security, the name can be
self-certifying. That is, if the application that runs on top of
InHome wants to verify that the content it receives via InHome from
another client is correct, it can use self-certifying names such as a
hash of the content. The check for correctness is then done at the
application level. If the data is found to be incorrect, it is left to
the application to react to this. For example, it can choose to fall
back to the origin server for that data.

$get$ is a blocking function and it does not return until it finds the
data, confirms the data is not in the cache, or times out. The $get$
function uses consistent hashing to locate the data, which we describe
in Section \ref{sec:Search}.