the ONE无线网络模拟器（Opportunistic Network Environment simulator ）

The ONE v1.2 - Readme ===================== The ONE is a Opportunistic Network Environment simulator which provides a powerful tool for generating mobility traces, running DTN messaging simulations with different routing protocols, and visualizing both simulations interactively in real-time and results after their completion. Quick start =========== Compiling --------- You can compile ONE from the source code using the included compile.bat script. That should work both in Windows and Unix/Linux environment with Java 6 JDK or later. If you want to use Eclipse for compiling the ONE, since version 1.1.0 you need to include some jar libraries in the project's build path. The libraries are located in the lib folder. To include them in Eclipse, assuming that you have an Eclipse Java project whose root folder is the folder where you extracted the ONE, do the following: select from menus: Project -> Properties -> Java Build Path Go to "Libraries" tab Click "Add JARs..." Select "DTNConsoleConnection.jar" under the "lib" folder Add the "ECLA.jar" the same way Press "OK". Now Eclipse should be able to compile the ONE without warnings. Running ------- ONE can be started using the included one.bat (for Windows) or one.sh (for Linux/Unix) script. Following examples assume you're using the Linux/Unix script (just replace .sh by .bat for Windows). Synopsis: one.sh [-b] [conf-file] [run-index (count)] Options: -b Run simulation in batch mode. Doesn't start GUI but prints information about the progress to terminal. Parameters: conf-file: The configuration file where simulation parameters are read from. run-index: If running in GUI mode (without -b option), you can give which run index to use in the given run. In batch mode, the last parameter is the run index count, i.e., how many runs with different run index are done. Configuring =========== All simulation parameters are given using configuration files. These files are normal text files that contain key-value pairs. Syntax for most of the variables is: Namespace.key = value I.e., the key is (usually) prefixed by a namespace, followed by a dot, and then key name. Key and value are separated by equals-sign. Namespaces start with capital letter and both namespace and keys are written in CamelCase (and are case sensitive). Namespace defines (loosely) the part of the simulation environment where the setting has effect on. Many, but not all, namespaces are equal to the class name where they are read. Especially movement models, report modules and routing modules follow this convention. Numeric values use '.' as the decimal separator and can be suffixed with kilo (k) mega (M) or giga (G) suffix. Boolean settings accept "true", "false", "0", and "1" as values. Many settings define paths to external data files. The paths can be relative or absolute but the directory separator must be '/' in both Unix and Windows environment. Some variables contain comma-separated values, and for them the syntax is: Namespace.key = value1, value2, value3, etc. For run-indexed values the syntax is: Namespace.key = [run1value; run2value; run3value; etc] I.e., all values are given in brackets and values for different run are separated by semicolon. Each value can also be a comma-separated value. For more information about run indexing, go to section "Run indexing". Setting files can contain comments too. A comment line must start with "#" character. Rest of the line is skipped when the settings are read. This can be also useful for disabling settings easily. Some values (scenario and report names at the moment) support "value filling". With this feature, you can construct e.g., scenario name dynamically from the setting values. This is especially useful when using run indexing. Just put setting key names in the value part prefixed and suffixed by two percent (%) signs. These placeholders are replaces by the current setting value from the configuration file. See the included snw_comparison_settings.txt for an example. File "default_settings.txt" is always read and the (optional) configuration file given as parameter can define more settings or override some (or even all) settings in the default settings file. The idea is that you can define in the default file all the settings that are common for all the simulations and run different, specific, simulations using different configuration files. If your simulations don't have any common parameters (which is highly unlikely) just provide an empty default settings file. If you want to use more than one default configuration set, just create separate folders for all configuration sets and provide one default settings file for each folder. Run indexing ------------ Run indexing is a feature that allows you to run large amounts of different configurations using only single configuration file. The idea is that you provide an array of settings (using the syntax described above) for the variables that should be changed between runs. For example, if you want to run the simulation using five different random number generator seeds for movement models, you can define in the settings file the following: MovementModel.rngSeed = [1; 2; 3; 4; 5] Now, if you run the simulation using command: one.sh -b my_config.txt 5 you would run first using seed 1 (run index 0), then another run using seed 2 etc. Note that you have to run it using batch mode (-b option) if you want to use different values. Without the batch mode flag the last parameter is the run index to use when running in GUI mode. Run indexes wrap around: used value is the value at index (runIndex % arrayLength). Because of wrapping, you can easily run large amount of permutations easily. For example, if you define two key-value pairs: key1 = [1; 2] key2 = [a; b; c] and run simulation using run-index count 6, you would get all permutations of the two values (1,a; 2,b; 1,c; 2,a; 1,b; 2,c). This naturally works with any amount of arrays. Just make sure that the smallest common nominator of all array sizes is 1 (e.g., use arrays whose sizes are primes) -- unless you don't want all permutations but some values should be paired. Movement models --------------- Movement models govern the way nodes move in the simulation. They provide coordinates, speeds and pause times for the nodes. The basic installation contains 5 movement models: random waypoint, map based movement, shortest path map based movement, map route movement and external movement. All models, except external movement, have configurable speed and pause time distributions. A minimum and maximum values can be given and the movement model draws uniformly distributed random values that are within the given range. Same applies for pause times. In external movement model the speeds and pause times are interpreted from the given data. When a node uses the random waypoint movement model (RandomWaypoint), it is given a random coordinate in the simulation area. Node moves directly to the given destination at constant speed, pauses for a while, and then gets a new destination. This continues throughout the simulations and nodes move along these zig-zag paths. Map-based movement models constrain the node movement to predefined paths. Different types of paths can be defined and one can define valid paths for all node groups. This way e.g., cars can be prevented from driving indoors or on pedestrian paths. The basic map-based movement model (MapBasedMovement) initially distributes the nodes between any two adjacent (i.e., connected by a path) map nodes and then nodes start moving from adjacent map node to another. When node reaches the next map node, it randomly selects the next adjacent map node but chooses the map node where it came from only if that is the only option (i.e., avoids going back to where it came from). Once node has moved trough 10-100 map nodes, it pauses for a while and then starts moving again. The more sophist