Over the weekend, I worked on getting the Thoth voronoi based area of interest management integrated into the Prime Mover event driven simulation framework. This integration required me to actually come up with how the Thoth perceptrons (i.e. the entity responsible for the AOI management) interacted with the simulation entity the perceptron was working for. Not really a big deal by any measure, but it was on my to do list. The actual integration into Prime Mover was simply the adding of the @Entity annotation which indicates that instances of the class are simulation entities and viola, it’s a simulation. I had purposefully designed the Node interface protocol to conform to the event constraints, so no changes were required. However, the simulation did require that there be a disconnect between the nodes, themselves, and the representation of the neighboring nodes that each node has.
In the original VAST model, this was done by the P2P network emulation which essentially serialized the nodes and reconstituted them when the P2P messages were received. I really, really hated the whole P2P emulation framework that was there and completely eliminated it in the integration. The message processing was problematic and caused me unnecessary pain and suffering in the actual simulation of the protocol anyway. Seeing as how I’m going to be using Coherence under the covers to make this puppy work, that means I’m going to have a different mechanism for communication anyway – the network model in VAST was way off base for what I had in mind.
Further, one of the practical drivers for getting the Thoth/Prime Mover integration was simply so that I could actually simulate the AOI maintenance protocol so I could see what the heck was going on under the covers and verify/debug the actual behavior under more realistic scenarios that I was interested in. If you watch the previous Thoth Applet, or even the original VAST demo applet, you’ll see flaws in the system where there are red dots without a blue circle around them. This flaw indicates that the selected node thinks the neighbor is at position X when the node in question is at position Y. Trying to debug this was a nightmare and I wasn’t sure if these flaws were simply the way things were in the protocol or if they were simply an artifact of the way the messages were processed in the demo code – if you take a look under the hood, you’ll see it’s kind of cheesy. Basically, each node processes all its messages until done and then on to the next node to do the same. Hardly what actually happens in a real system.
So, enter event driven simulation. All the messages between the perceptrons are – you guessed it – events. I built a small wrapper class which provides the same kind of indirection between the nodes that a network provides. This Node class simply posts events to the actual perceptron it wraps. Very simple and very elegant. Now, in the wrapper class, I just add a random number generator which provides network jitter by “sleeping” a random time before posting the event, and viola. A complete simulation of the system. Now I just moved the previous simulation behavior into a simple simulation entity and attached the sims to the perceptrons and now I have a self driven simulation. I can perform far more complex simulations using think time, etc and because I’m using event driven simulations, I can – naturally – perform the simulation in a fraction of the “real time” it would take to run the same thing computationally. Sweet.
In the process, I added a pretty nice JUnit testing framework for the Prime Mover simulation framework. Given that Prime Mover has to actually perform byte code surgery on the classes making up the simulation, it was extremely awkward to have to use reflection to deal with the class loader barrier. So, I borrowed the same technique we use in the Spring-DM framework to run JUnit tests inside the OSGi framework – basically a clever bouncing and reloading of the JUnit test case between class loaders. It was far simpler in the Prime Mover case as I have common classes between the class loaders in question. The result is pure bliss, though, as I can now deal directly with the simulation entities, classes, etc without having to interact with them through reflection. Quite cool and something that will obviously come in quite handy as I do more work with Prime Mover.
Also, I wanted to change the demo applet to actually use this now simulation driven AOI system. This involved significantly less surgery than I expected and the result is very nice. I simply added a new stepping simulation controller which allows me to advance the simulation until all the current events are consumed. This works out quite nicely as even the drawing operations are actually triggered by events in the simulated entities – a milestone I thought I’d have to wait for.
In any event, the next step in the process is a lot easier now. I have a very nice predator/prey simulation based on the Boid flocking model – complete with graphics – and I’m going to take the Thoth AOI framework and recast the predator/prey simulation under Prime Mover using Thoth AOI for the simulated predators and simulated prey as their mechanism for interacting/discovering the neighbors they need to interact with. Accomplishing this will be a major milestone in the long and winding path to the full vision of 3rd Space as this system will show all the major components working in harmony. After this is accomplished I can next move on to getting the system to run on top of Coherence where I can then work on the actual scalability experiments, running the whole system on Amazon’s EC2.
Stay tuned. It should be fun.