% Results chapter

\svnInfo $Id$

\chapter{Results}
\label{ch:results}

We did several tests for the \vampeer{} library to show that the code works.
There are some smaller examples, the Origo example, a benchmark and some unit
tests. While we already mentioned all the examples, we would like to present the
benchmark and the test results now.

\section{Benchmark}

Since \vampeer{} is going to be used for Origo which should be able to process
many messages, we have to show that our library is able to handle much traffic
and that it can process messages correctly.

Thus, we created a benchmark which is also shipped as an example. The benchmark
consists of two peers, a master node and a slave node. The peers reside in the
NPG and use discovery requests to find each other.

The master creates random strings and sends endpoint messages to the slave which
uppercases the message contents and sends them back. The master checks at the
end whether it has received all messages and whether the content was valid.

The master sends by default 1000 messages which is done in few seconds.
\vampeer{} successfully passes this test as shown in
listing~\ref{lst:results_benchmark}.

\begin{lstlisting}[language=, caption={Benchmark output}, label=lst:results_benchmark]
2007/02/27 13:54:10.710 - FATAL - benchmark master: creating test data
2007/02/27 13:54:10.844 - FATAL - benchmark master: sending messages now, count: 1000
2007/02/27 13:54:14.533 - FATAL - benchmark master: message sending completed
2007/02/27 13:54:19.536 - FATAL - benchmark master finished successfully
2007/02/27 13:54:19.759 - FATAL - benchmark slave: gracefully stopped
\end{lstlisting}

We see that the application works quite fast. To get such results, we have to
finalize the code and turn the contract checking off. Else, it would last much
longer. Especially the preconditions when parsing XML with the Gobo library
take a lot of time.

\section{Unit tests}

To test some individual classes, we implemented some unit tests. There exist
tests for the data classes that are used everywhere in the library. As it would
be very cumbersome to have errors in these classes, we implemented tests for
some advertisements, for the endpoint message and for all IDs.

The tests use the \emph{getest} testing library by Gobo.

\begin{lstlisting}[language=, caption={Unit test results},
label=lst:result_unittests]
Test Summary for unit_tests

# PASSED:     44 tests
# Failed:     0 test
# Aborted:    0 test
# Total:      44 tests (1443 assertions)
\end{lstlisting}

\section{Summary}

In this master thesis, we built an Eiffel binding for JXTA. Although the
implementation is far from being complete, the available parts are functioning
and ready to use within Origo.

Speaking in JXTA terms, our \vampeer{} library provides the following services:

\begin{itemize}

\item The \emph{endpoint service} handles incoming and outgoing messages and
serves as a central point for other services. When messages are to be sent, the
endpoint passes them to the correct transport module. Received messages from the
network are passed from the transport modules to the endpoint service, which
leads them to the appropriate service.

\item We implemented a \emph{TCP transport module} because it is simple and
fast. It maintains a queue for outgoing messages and manages TCP connections
with remote peers. It is able to generate and parse the wire message
representation.

\item Our \emph{endpoint router} is very small and only provides the most
essential feature: It resolves peer IDs to real destination endpoint addresses,
namely for the TCP transport. It cannot send remote queries to get a peer's
route information. The routes have to be available already when sending a
message.

\item Our \emph{rendezvous service} implements just parts of the protocol. It
only acts as an edge peer meaning that \vampeer{} is always in need of an
external rendezvous server to be able to propagate messages within the peer
group\footnote{But we do supply such a rendezvous server. It uses the JXTA's
reference implementation and is therefore written in Java.}. An edge peer is
able to propagate messages to its rendezvous server.

\item The \emph{resolver service} is fully implemented in \vampeer\@. It
provides a query-response system and may use the rendezvous to propagate a
message.

\item The \emph{discovery service} serves as an advertisement storage and is
used to query for advertisements, locally and remotely. Our discovery is also
able to push SRDI messages to the rendezvous.

\end{itemize}

\vampeer{} is currently only able to run \emph{one} peer group besides the WPG
(which is only used for platform managing). But it is fully possible to replace
the standard NPG with a private peer group.

Looking at the requirements in section~\ref{sec:design_requirements}, we have
successfully fulfilled our task. With \vampeer, we are able to discover other
peers and are able to communicate with them using an own infrastructure.

There is nevertheless the restriction that the user has to ensure the
availability of the recipient peer's route information when sending a message.
This can be easily done by once sending a peer discovery query and publish the
results locally to the advertisement storage. As advertisements are subject to
expiration, we will have to unset the lifetime before storing or to query again
after a certain time.

We have well demonstrated how the library can be used by explaining the coarse
API and by showing some examples: While the endpoint message example only
focuses on the endpoint service, the discovery example describes how to search
for remote peers. We also looked at a bigger example and argued how Origo could
implement its messaging layer.

With these results, we release the first version of \vampeer\@.
