SimNet

This simulates a vhf radio store-and-forward message network. Like the network it imagines, the simulator produces chaotic behavior that has been a lasting subject of study, first coded in batch pascal, then translated to interactive java.

See historical Radio Network Simulator

See responsibilities of SimNet Classes

The current java version is open source. github

I'd be interested in refactoring the event-oriented java version into a process-oriented version in the style of Simula. To that end I have created this overview of the most active components of the current implementation.

Keld Helsgaun describes various approaches to Discrete Event Simulation in Java.

One event queue, declared in Simulator, holds the known future activity of the simulator. github

One event loop, declared in SimNet, pulls events from the queue advancing the clock accordingly. github

One case statement, declared in EventBlock, dispatches activity to event handlers in the network. github

Each Station has a queue of Messages in transit which it forwards on a first come first served basis. github

Each Station has a routing table that suggests a next hop based on the destination address and how much it differs from its own. github

Each Station estimates ultimate transit time for new messages based on its own backlog and what it learns from neighbors. github

The Panel runs on its own thread reading and rendering information available in the simulator state. github

The Panel locates information in rectangular coordinates roughly aligned with a basemap. github

The Panel renders the network as dots connected by lines with optional city names when there is room. github

The Panel renders message backlogs as bubbles that grow in area proportional to message count. github

The Panel renders messages in flight as bold lines between stations. github

The Panel samples routing tables to render likely routes to and from selected stations. github

Plan A

Change the Simulator to launch tasks for each actor. Rely on the built-in task scheduling to coordinate activity.

Change the Stations to loop waiting for new messages or the opportunity to forward old ones.

Change the Visualization to instrument actors as if they were any other system under surveillance. Aggregat events when they happen faster than the visualization can render.

Helsgaun's work suggests that high arrival rates requires thread pools for efficiency. Perhaps a Message should be other than an actor.

Plan B

What other ways might an event-oriented simulator exploit multiple cores? Maybe N event queues for N cores?

Plan C

Jeff Berkowitz suggests N worker threads dispatching events from a single event queue using a highly optimized queue from util/concurrent.