peersim.edsim
Class EDSimulator

java.lang.Object
  peersim.edsim.EDSimulator

public class EDSimulator
extends java.lang.Object

Event-driven simulator engine. It is a fully static singleton class. For an event driven simulation the configuration has to describe a set of Protocols, a set of Controls and their ordering and a set of initializers and their ordering. See parameters "init", "control".

One experiment run by nextExperiment() works as follows. First the initializers are run in the specified order. Then the first execution of all specified controls is scheduled in the event queue. This scheduling is defined by the Scheduler parameters of each control component. After this, the first event is taken from the event queue. If the event wraps a control, the control is executed, otherwise the event is delivered to the destination protocol, that must implement EDProtocol. This is iterated while the current time is less than "simulation.endtime" or the queue becomes empty. If more control events fall at the same time point, then the order given in the configuration is respected. If more non-control events fall at the same time point, they are processed in a random order.

The engine also provides the interface to add events to the queue. Note that this engine does not explicitly run the protocols. In all cases at least one control or initializer has to be defined that sends event(s) to protocols.

Controls can be scheduled (using the Scheduler parameters in the configuration) to run after the experiment has finished. That is, each experiment is finished by running the controls that are scheduled to be run after the experiment.

Any control can interrupt an experiment at any time it is executed by returning true in method Control.execute(). However, the controls scheduled to run after the experiment are still executed completely, irrespective of their return value and even if the experiment was interrupted.

CDScheduler has to be mentioned that is a control that can bridge the gap between peersim.cdsim and the event driven engine. It can wrap CDProtocol appropriately so that the execution of the cycles are scheduled in configurable ways for each node individually. In some cases this can add a more fine-grained control and more realism to CDProtocol simulations, at the cost of some loss in performance.

When protocols at different nodes send messages to each other, they might want to use a model of the transport layer so that in the simulation message delay and message omissions can be modeled in a modular way. This functionality is implemented in package peersim.transport.

See Also:

Configuration

Parameter Summary

simulation.endtime
The ending time for simulation.

simulation.logtime
This parameter specifies how often the simulator should log the current time on the standard error.

simulation.eventqueue
This parameter specifies the event queue to be used.

init
This is the prefix for initializers.

control
This is the prefix for Control components.

Method Summary

static void	add(long delay, java.lang.Object event, Node node, int pid) Adds a new event to be scheduled, specifying the number of time units of delay, and the node and the protocol identifier to which the event will be delivered.
static boolean	isConfigurationEventDriven() This method is used to check whether the current configuration can be used for event driven simulations.
static void	nextExperiment() Runs an experiment, resetting everything except the random seed.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Parameter Detail

simulation.endtime

The ending time for simulation. Only events that have a strictly smaller value are executed. It must be positive. Although in principle negative timestamps could be allowed, we assume time will be positive.

simulation.logtime

This parameter specifies how often the simulator should log the current time on the standard error. The time is logged only if there were events in the respective interval, and only the time of some actual event is printed. That is, the actual log is not guaranteed to happen in identical intervals of time. It is merely a way of seeing whether the simulation progresses and how fast...

simulation.eventqueue

This parameter specifies the event queue to be used. It must be an implementation of interface PriorityQ. If it is not defined, the internal implementation is used.

init

This is the prefix for initializers. These have to be of type Control. They are run at the beginning of each experiment, in the order specified by the configuration.

See Also:

Configuration

control

This is the prefix for Control components. They are run at the time points defined by the Scheduler associated to them. If some controls have to be executed at the same time point, they are executed in the order specified in the configuration.

See Also:

Configuration

Method Detail

isConfigurationEventDriven

public static final boolean isConfigurationEventDriven()

This method is used to check whether the current configuration can be used for event driven simulations. It checks for the existence of config parameter "simulation.endtime".

nextExperiment

public static void nextExperiment()

Runs an experiment, resetting everything except the random seed.

add

public static void add(long delay,
                       java.lang.Object event,
                       Node node,
                       int pid)

Adds a new event to be scheduled, specifying the number of time units of delay, and the node and the protocol identifier to which the event will be delivered.

Parameters:

delay - The number of time units before the event is scheduled. Has to be non-negative.

event - The object associated to this event

node - The node associated to the event.

pid - The identifier of the protocol to which the event will be delivered