A Distributed Swarm Model is now functioning

[John Sauter]

I wanted to let you all known about an IR&D project we are doing at ERIM
that we hope will provide a broader benefit to the Swarm community. 
Back in early 1990, a team of researchers now at ERIM invented a mechanism
to tie together different simulation tools so you could run a distributed
model across a network. We all know that this is a hard problem. If you
review the literature in this field you will see that there is still no
general purpose solution to the problem of synchronizing a distributed
simulation. We took a pragmatic approach to the problem and through several
years of some clever engineering and tuning developed a protocol that solved
the problem while maximizing the performance of the system. We called the
technology Syncer. We built several versions of the software mainly for use
with a consulting business we had that developed detailed simulation models
of manufacturing systems and designed coordination and control strategies to
solve complex problems. 

Syncer has lain dormant since that time, a product apparently ahead of its
time. Since then the defense community has built a couple of standards for
distributed simulation. The latest is called HLA which is soon to become an
IEEE standard. It is a large (300 page), complex system that focuses on
integrating distributed simulation platforms rather than optimizing the
performance of the overall model. With Syncer, we wanted to integrate
different tools, but also looked for the performance gains that come from
running the model across multiple processors. From what I can tell Syncer is
still the most compact (described in 20 pages), high performance algorithm
for performing this critical function. Someone should still probably do an
HLA interface to Swarm, but we wanted something simple, compact, and fast
that would allow us to get performance improvements from distributing a
Swarm model over several computers.

We recently started a project where we needed to test the performance of a
scheduling algorithm (developed on Voyager) against a model of a
semiconductor plant (developed in Swarm). In order to tie these two
environments together we needed to resurrect Syncer. So we dusted off the
Syncer algorithms and proceeded to work out the details. 

There are a number of issues that need to be addressed in a distributed
simulation environment. The first (and not the most trivial) is an
environment to support the remote invocation of methods. We developed an
approach with Syncer, but since that time a number of technologies have been
developed to address this problem. We looked at Microsoft (with DCOM and
SOAP), OMG (with CORBA), and Java (with RMI). We have currently settled on a
Java RMI approach, but the basic technology can work with any of the
methods. The architecture we have developed will support any language.

We also needed a specialized IDL compiler. We have developed a simple one
for now. It creates all the classes required for both the RMI support as
well as the connection required for Syncer. We are currently building the
interface for Java Swarm. Objective C will follow. 

We have successfully run a distributed Swarm model (our first step). It is a
simple dual Swarm model where agents schedule events on the remote Swarm. We
have run into a number of problems and issues and are working with the Swarm
developers to get these resolved. But the basic algorithms appear to be
functioning.

We have some more work to do to make the implementation more robust and
general purpose. We will be looking at some simple performance tests to see
what kind of improvements we can get from distributed computing (though this
is heavily application dependent). We may also request some changes to Swarm
that will allow us to perform some Syncer functions more efficiently than we
can with the current API.

One of the objectives of the effort was to place as small a burden on the
application developer as possible. Towards that end, creating a distributed
Swarm model will be no more difficult than coding a distributed application
with RMI. Typically that means exposing an interface for every class that
can be invoked remotely. The compiler uses those interfaces to build the
stubs and skeletons that RMI and Syncer require. Objective C support will
take longer since we are not aware of any RMI support for Objective C. If
anyone has suggestions for things we can look at, let us know.

An obvious question is what will we do with this code when we are done. I am
still working out the details with our business folks, but I am confident
that we can arrange for free availability of the code for academic use. 

Please contact me directly if you have questions or are interested in being
informed of future developments. 

John A. Sauter  
Center for Electronic Commerce
ERIM
(734)-623-2513

 <<John A. Sauter.vcf>>

John A. Sauter.vcf
Description: Binary data