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
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.
What other ways might an event-oriented simulator exploit multiple cores? Maybe N event queues for N cores?
Jeff Berkowitz suggests N worker threads dispatching events from a single event queue using a highly optimized queue from util/concurrent.