The overall architecture of Nest is depicted in the figure (1)above. 

Nest consists of a simulation server and client monitors.
The simulation server is responsible for the execution of a
simulation run. 

The generic client monitors are used to
(re)configure a simulation model and control its execution. 

The custom clients are used to monitor a simulation behavior and
display the results. 

Clients can (and typically will) reside on separate machines from the server.

This allows dedication of a
computing server to execute a cycle-consuming simulation while
delegating presentation and control functions to remote
workstations.


The client-server communications require relatively low
communication bandwidth. This permits the server to serve
remote clients over a wide-area network. 

Thus, it may be
necessary sometime to utilize the power of a remote
supercomputer to execute a complex simulation study.



The interaction of users with Nest are depicted via the shaded
arrows. Users provide node and link functions which are linked
with the simulation server to form a simulation testbed. These
functions are coded in C and include calls upon the Nest library.
Node functions are used to model distributed communicating
processes running at network nodes (e.g., protocols, database
transactions, manufacturing cells). Nest executes the node
processes and their communications calls using Nest-provided
primitives for sending, broadcasting or receiving packets.


A simulated link has an associated stack of link functions. The
motion of a packet over the link is simulated by passing it
through the link functions, which act as a stack of filters. Link
functions are used to model the behavior of communication
links (e.g., packet loss, link jamming, support of a standard
protocol stack). Link functions are also used to monitor and
collect performance statistics of link traffic (e.g., number of
control packets, link delay).


The simulation server integrates the node and link functions to
form a single simulation process. The simulation process
schedules the execution of the node and link processes to meet
the specifications of delay and timing set by the users. The user
can control the timing of events and the delays associated with
communications through a collection of Nest-supported timing
control functions. These functions simulate standard Unix
timing control (e.g., sleep) and support full user control over
simulation time.


 NEST USER INTERFACES


Nest users control and manage a simulation through graphical
monitoring tools. Nest provides two kinds of monitors: generic
monitor and custom monitors. 

The generic monitor provides a
complete environment to create edit and (re)configure simulation
scenarios.The user creates and modifies a network description
using a mouse to draw it; clicking on the mouse generates nodes;
dragging the mouse between nodes creates links. Node and link
pop-menus offer a range of editing features to configure the
respective simulated objects. Simulation parameters may be set
via respective panels at the top. Once the user defined a
simulation scenario, it is sent to the simulation server where it is
loaded and executed.


One of Nest's key features is the ability to reconfigure a scenario
during the simulation run. This is particularly important for
studies of complex dynamic system behaviors: how does the
system respond to a node/link crash? how will it handle addition
of new nodes or links? what transient behaviors occur as a result
of such critical changes? how long will certain transients last?
how probable are they? These type of questions are typically
difficult to answer through analytical studies or model-based
simulation and require significant experimentation. Nest support
such experimentation with varying scenarios. Users may
delete/add nodesflinks or change their features while the
simulation is running. The impact of these changes on the
system behavior may be instantly observed and interpreted.
Nest's custom monitors offer tools to display the results of a
simulation. A user may view the status and data associated with
different nodes or performance statistics of interest. The custom
monitors may be used to animate the dynamics of the simulation
behavior and represent the evolution of local partial views of the
system state. This is particularly useful in the study of complex
dynamical behaviors of distributed systems.