






ODIN Notes
Node Creation
randomwalksim:
- tracefile has a line like "50. C 2.0.1.143:2000". C for Creation.
- kernel/TraceWorkloadExecutive.cc reads this line and later calls PeerController::createPeer
- PeerController::createPeer is purely virtual, but subclass kernel/PeerExecutive.cc at least creates a new Runtime (a SimRuntime, specifically) and then creates a new PeerLogic and a new TopologyManager using factory methods.
randomwalkpeer:
- A new PlatformRuntime is created.
- A new PeerLogic is created by calling the ExtensiblePeerLogicFactory's ExtensiblePeerLogicFactory::newPeerLogic method which examines the PeerLogic class requested in the properties file specified on the command-line.
- Same deal for TopologyManager/TopologyManagerFactory.
Note that when randomwalkpeer's main() is called, that right there is pretty much the creation of the node. If we handle sims and real peers somewhat separately, our solution could be as simple as a printf somewhere in randomwalkpeer's main.
Node Destruction - a possible path
randomwalksim:
- tracefile has a line like "10000. T 2.0.1.143:2000". T for Terminate.
- kernel/TraceWorkloadExecutive.cc calls PeerController::terminatePeer, also a pure virtual
- kernel/PeerExecutive.cc eventually calls Runtime::terminate which tells the factory-created PeerLogic and TopologyManager to terminate, and then deletes the objects. (There are subclasses of Runtime, but they don't appear to override terminate.)
- In the case of rwalksim's PeerLogic (RandomWalkPeerLogic) and TopologyManagers (MinDegreeTopologyManager and SquareRootTopologyManager) terminate() does nothing.
Link Creation
There are different types of connections that can be established between peers. The one we primarily think of and are probably most interested in are SearchConnections (#1000). If we can overlay the different types or give the user the option to switch between connection types, all the better.
- Soon after a new BasicPeerLogic/RandomWalkPeerLogic object is created, its registerWithHostcatcher method is called. In there its assumed the TopologyManager will be a subclass of HostcatcherBasedTopologyManager, and its HostcatcherBasedTopologyManager::checkNeighbors method is called.
- In subclass rwalksim/MinDegreeTopologyManager.cc at least, checkNeighbors establishes a HostcatcherQueryConnection-type connection (#10001) to the hostcatcher using getRuntime()->getCommunicationManager()->makeConnection. Then it sends a HostcatcherQueryMessageType message (#102). The message includes the number of random peers to send back.
- common/Hostcatcher.cc's handleMessage gets N from the message, picks N peers at random, and sends that back in a HostcatcherQueryResultMessageType message (#103). This is message is sent on the existing HostcatcherQueryConnection-type connection.
- rwalksim/BasicPeerLogic.cc's handleMessage again assumes the TopologyManager will be a subclass of HostcatcherBasedTopologyManager and calls HostcatcherBasedTopologyManager::addNeighbors.
- At least in rwalksim/MinDegreeTopologyManager.cc, attempts to establish SearchConnections (#1000) are made using getRuntime()->getCommunicationManager()->makeConnection. When successful, these SearchConnection links are probably the primary topology we envision.
In both cases above, makeConnection in peer/CommunicationManager.cc calls the ConnectionFactory's requestConnection. In subclass kernel/NetworkEmulatorExecutive.cc, goes on to call the other method ConnectionFactory::createConnection,
but this is not true of subclass platform/SocketManager.cc. So to catch all connections being created regardless of thier (object) type, I'd think we'd want to be notified about every call to Connection::Connection or every call to ConnectionFactory::requestConnection and either way somehow get the new Connection object (e.g. make our own ConnectionFactory that wraps/contains a real ConnectionFactory).
Link Destruction
Once we get hold of a reference to a new Connection (as described above), we can register as a ConnectionClosedListener.
Then we'll know when the link closes.
Link Activity: Messages
Once we get hold of a reference to a new Connection (as described above), we can register as a ConnectionStatusListener.
Then the subclass methods NetworkEmulatorConnection::enqueueMessage or SocketConnection::enqueueMessage will tell us when a message has been received. (I think when ConnectionStatusListener::connectionStatusChanged is called, we can check Connection::readyToClose. If that's 0, then something else changed the status and its most likely a message. If that's not a safe assumption, we could monitor calls either to CommunicationManager::sendMessage (outgoing) or PeerLogic::handleMessage (incoming). The CommunicationManager isn't subclassed (yet anyway), so if have to modify an existing class that might be a better route.)
Link to this Page
- Team SPEW last edited on 13 March 2006 at 8:57 pm by r69h15.res.gatech.edu