The PeerSim simulator.

See:
Description

Peersim

peersim	The main entry points for Peersim.
peersim.cdsim	The cycle-driven simulator.
peersim.config	Configuration management.
peersim.core	Core classes.
peersim.dynamics	Control classes for initializing a network or modifying it during simulation.
peersim.edsim	The event-driven simulator.
peersim.graph	Graph data structures, i/o utilities and algorithms.
peersim.rangesim	The PeerSim range simulator, that allows the definitions of ranges for variables.
peersim.reports	Observer classes providing generic information about a network.
peersim.transport	Classes and interfaces for simulating transport-level communication in overlay networks.
peersim.util	Utility classes.
peersim.vector	Classes that make it possible to modify and analyze numeric vectors defined by the vector of protocol instances in the network.

Examples

example.aggregation	Aggregation example described in Peersim tutorial 1.
example.edaggregation	Event driven aggregation example described in Peersim tutorial 3.
example.hot	Topology generator example described in Peersim tutorial 2.
example.loadbalance	Load balancing example described in Peersim tutorial 1.
example.newscast	Newscast code needed by the aggregation and load-balancing examples described in Peersim tutorial 1.

The PeerSim simulator. Here we list some miscellaneous assumptions and contracts that hold for the entire system. Browsing the class documentation can best be started at Simulator, which is the main class and contains pointers to browse further.

Conventions over Logging

There is no strict logging system that enforces a certain way of producing the output of the simulation. Instead we have a few rules that are respected by the components of the system. By default, output is printed to the standard output, and error, warning and debug messages go to the standard error. The output also follows some conventions.

In particular, Controls used to observe the simulation print information each time they are called using the following format. They first print their own name in the configuration, immediately followed by a colon, immediately followed by at least one whitespace character. For example, control.0: . The name does not contain any whitespace. After this arbitrary information is printed. The last character printed is always a newline. In practice, most components output a single line only. Also, the components use only the print and println methods. Some controls write to a file if configured to do so.

It is possible to capture the output by redirecting it to a custom written PrintStream class. Relying on the above rules, it is possible to meaningfully parse and process the output if necessary. Class Simulator offers a configuration property where one can set the PrintStrem class and its optional configuration options.

Conventions over Exceptions

We do not always document three kinds of exceptions: RuntimeException, IllegalParameterException and MissingParameterException. The last two are thrown when there is a problem while reading the configuration. The RuntimeException is thrown in case of any other problem during the running of the simulator such as file i/o, etc. We always document those exceptions that are different from these three or that are explicitly declared in the API.

Note that the component that actually handles these exceptions is the main class Simulator. It always exits as a result of any exceptions, after attempting to dump some information about the details of the failure on the standard error. This is the main reason why we are intentionally sloppy about documenting all the exceptions.