The PeerSim simulator.

See:
          Description

Peersim
peersim  
peersim.cdsim  
peersim.config  
peersim.core  
peersim.dynamics  
peersim.edsim  
peersim.graph  
peersim.rangesim  
peersim.reports  
peersim.transport  
peersim.util  
peersim.vector  

 

Examples
example.aggregation  
example.edaggregation  
example.hot  
example.loadbalance  
example.newscast  

 

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.