\subsection{Micro Benchmarks}

From a client's point of view, the overhead of executing applets remotely and
the overhead of passing messages between remote applets are of great interest.
We present experimental results for our implementation, and discuss their
implications for using the proposed infrastructure. Table~\ref{microbenchmarks}
summarizes the micro benchmarks of our infrastructure in a LAN.


\subsubsection{Remote Execution of Applets}

To be executed by a host, an applet is uploaded to a server, and its URL
is registered with a broker.  Then, the broker schedules it by passing
its URL to a host.  The host opens this URL and thereby downloads the embedded
applet, and pipes it to a Java VM.  Finally, any results are sent back to
the client via the server.  We implemented a micro-benchmark applet that
just returns a single byte to the client.  This
measures the overhead of downloading the applet and starting it.

%The composition of this inevitable overhead is shown in detail in Figure~{}.

%The client posts its applet to the broker, where a servlet enqueues it.  
%When a daemon polls the broker, the URL of a web page embedding the applet is
%sent to it.  Then, the daemon opens the URL, and thus invokes the embedded
%applet.  Our micro-benchmark applet immediately invokes a servlet at the
%broker to indicate that it is done.  Finally, the client polls the
%corresponding servlet at the broker site for results.

On a standard 10 Mbit Ethernet network the remote execution of our
micro-benchmark applet within Netscape 3.01 takes about two seconds.  However,
a substantial part of this overhead is caused by the underlying browser
starting a new Java thread.

%On a standard 10 Mbit Ethernet network, downloading and invoking an applet
%takes about 2 seconds for an idle broker.  This basic overhead increases as
%the work load at the broker increases.  However, a substantial part of it is
%caused by the underlying browser starting a new Java thread.  Notice that when
%running identical applets on different parameter sets this initial overhead
%can sometimes be reduced.  Applets that have finished may query the client or
%broker for new parameters before quitting the host to avoid the overhead of
%sending the same applet to a different host.  However, reloading it to the
%same host might take advantage of a cache provided by the used web browser.

This seems to imply that only coarse-grained applications can take advantage
of the proposed architecture.  On the other hand, the reader should not forget
that most parallel machines have similarly high start-up costs when spawning
parallel work.  Having paid this start-up cost, communication can now be
implemented more efficiently, as discussed next.

%Furthermore, applets that are done should ask the client or look at the broker
%site for new parameters before quitting the host to avoid the overhead of
%sending the same applet to a different host.  However, reloading it to the
%same host might take advantage of a cache provided by the used web browser.


\subsubsection{Message Passing}

As discussed in Section~\ref{design_implications}, messages between two applets
must be routed through the servers they were downloaded from.  Furthermore, the
Java VM requires all communication to go through the Java network layer
(implemented by the {\tt java.net} package) and the complete TCP or UDP stack
of the underlying OS.  This causes a substantial software overhead compared to
communication libraries of parallel machines.

%Since applets cannot open network connections to any site other than the one
%from which it was itself loaded, messages between two applets must be routed
%through the servers they were loaded from.

%Furthermore, the Java API only provides an interface to the TCP and UDP
%protocols.  Since applets are not allowed to listen for or accept network
%connections on any port of the local system, the broker cannot send datagrams
%to an applet.  Thus, any message passing between applets must be based on
%TCP.

%Basically, there are two possibilities to
%enable message passing.  Either a permanent socket connection can be
%established or a connection-less protocol such as HTTP can be used.

%As discussed in Section \ref{design:communication} message passing can either
%be implemented by linking two permanent or two temporary socket connections
%(possibly running a connection-less protocol such as HTTP).

Using Javelin with TCP/IP sockets, a single message can be sent from one applet
to another within 6-7 milliseconds on a standard 10 Mbit Ethernet LAN.  As long
as applications are coarse-grained, the overhead of opening a socket connection
can be ignored.

%When HTTP is used, the receiver must either poll the broker site continuously
%or the response to its request for the message must be delayed until it
%arrives.  Applying the latter technique, a single message takes about 135
%milliseconds.

Since message passing using Java TCP and UDP sockets is slow compared to
dedicated parallel machines, and large networks of heterogeneous machines
cause unpredictable communication delays, only computation-intensive parallel
applications benefit from the proposed infrastructure.

\begin{table}
\begin{center}
\begin{tabular}{|l|l|} \hline
Overhead & ms\\ \hline\hline
Applet Start-up Time& 2000\\ \hline
Send/Receive & 6-7\\ \hline
\end{tabular}
\end{center}
\caption{\em {Micro benchmarks for a 10 Mbit Ethernet LAN using TCP/IP sockets.}}
\label{microbenchmarks}
\end{table}
