Today the team at the University of Düsseldorf and the University of Paderborn published a new version of PeerfactSim.KOM, which comes with a huge number of bug fixes, features and extensions. Stay tuned for the whole change log!
This version of PeerfactSim.KOM is based on PeerfactSim.KOM v4.0 – Fork UPB (2013-01-31).
For questions regarding this fork, please visit http://www.peerfact.com or write us an email: <firstname.lastname@example.org>
This current version comes with following extensions:
Part 1: New
Application layer – Monitoring:
– New SkyEye.KOM implementation with a few addons like MaliciousSkyEye and GossipSkyEye.
— Vanilla SkyEye: monitoring of deterministic functions (sinus, dirac, ziczac, rectangle) or gathered metrics by the local node (hops, response times etc.) using a tree structure. Aggregating bottom top the tree and disseminating the global view top bottom.
— Malicious SkyEye: SkyEye extension to handle malicious nodes.
— Gossip SkyEye: Enhancing the robustness of the SkyEye tree by using gossip connections.
— Check out the configurations under config/scenarios/monitoring/SkyEye*.xml, GossipSkyEye*.xml and MaliciousSkyEye*.xml
– New Push-sum implementation available: Push-Sum Implementation: like SkyEye it can monitor deterministic functions or gathered metrics by the local node but instead of using a structure (e.g. a tree) this approach is gossip-based, meaning each node selects a random neighbor to exchange its current view of the network. This approach is epoch based and approximates to the value at the beginning of an epoch after several rounds. Check out the configuration files under config/scenarios/monitoring/Gossip*
Churn layer – new churn generator:
– Used to generate churn events by using a specified model. This churn generator gives the opportunity to perform operations before going on- or offline. For this just use the ChurnListener in org.peerfact.api.common. The churn generator needs the start and stop time. For a config example refer to config/includes/churn/Graceful*Churn.xml files.
Service layer – replication:
– Ideal replication service uses a global defined DHT thus simulating an ideal replication service where, regardless of the churn level, the data is always available.
– New Kademlia implementation. Check out the configuration file config/scenarios/overlay/dht/kademlia2/kademlia2.xml.
– Education package: This package comprises two simple protocol implementations to ease first steps with the simulator. It contains a simple implementation of Chord and a simple P2P overlay in which nodes communicate with a node located in the center of the overlay. Configurations are given by config/education/star.xml and config/education/educhord.xml
– Social: The social layer is used to import/generate real-life social relationships into peerfact. Different models exist to do so. Currently the user can choose between different models. 1) social.dunbar allows either to load a file describing the social topology or to generate graphs according to the Barabasi-Albert model or the Small World Theorem. Models in social.dunbar generate graphs according to the Dunbar modesl, in which (ego-) nodes have a limited number of friends. 2) Models in social.graphstream use the GraphStream lib to build graphs. 3) Models in social.oracle provide a list of friendly nodes for each host, similar to the global oracle. Configs can be found in config/scenarios/tests/socialLayer/. An example application using the social layer is located in test/impl/application/social/.
– Geo: The geo layer is used to map locations (coordinates) to hosts. Locations are not necessarily bound to fixed coordinates. Moreover, hosts are able to move and change their positions. The dummy module is a simple (proof-of-concept) implementation of the geo layer. The modular package of the geo layer allows a modular configuration of the geo layer, similar to the modular netlayer. Example configurations are located in config/scenarios/tests/movementTests/. An example application using the geo layer can be found in test/impl/application/movementTestApplication/.
Part 2: Improvements
– Bug fixes in Pastry
– Bug fixes in Chord
– Batch Runner:
— rps flag for running plot scripts after the simulation. By default the flag is not set, so the plot scripts will not be run.
— ccs flag for not simulating but only concatenate data and create plot scripts. By default this flag is not set.