文件列表:

one (0, 2008-08-26)
one\HISTORY.txt (2480, 2008-08-26)
one\prophet_settings.txt (246, 2007-07-19)
one\test (0, 2008-08-26)
one\test\ConnectionTest.java (5352, 2008-08-20)
one\test\TestUtils.java (3312, 2008-08-20)
one\test\WKTPointReaderTest.java (1289, 2008-08-20)
one\test\AbstractRouterTest.java (4410, 2008-08-20)
one\test\CoordTest.java (747, 2008-08-20)
one\test\StationaryMovement.java (1222, 2008-08-20)
one\test\MessageChecker.java (3594, 2008-08-20)
one\test\PointsOfInterestTest.java (6329, 2008-08-20)
one\test\DijkstraPathFinderTest.java (2274, 2008-08-20)
one\test\EpidemicRouterTest.java (18208, 2008-08-20)
one\test\ExternalMovementReaderTest.java (1921, 2008-08-20)
one\test\MaxPropDijkstraTest.java (4382, 2007-11-21)
one\test\MapNodeTest.java (2181, 2008-08-20)
one\test\MaxPropRouterTest.java (9463, 2008-04-17)
one\test\WKTReaderTest.java (6918, 2008-08-20)
one\test\ContactTimesReportTest.java (4560, 2008-08-20)
one\test\MessageGraphvizReportTest.java (2134, 2008-08-20)
one\test\ExternalMovementTest.java (3345, 2008-08-20)
one\test\TestSettings.java (1560, 2008-08-20)
one\test\SettingsTest.java (5673, 2008-08-20)
one\test\ActivenessHandlerTest.java (1685, 2008-08-20)
one\test\DistanceDelayReportTest.java (2278, 2008-08-20)
one\test\TotalContactTimeReportTest.java (3761, 2008-08-20)
one\test\ExternalEventsQueueTest.java (2608, 2008-08-20)
one\test\package.html (168, 2007-07-19)
one\test\ProphetRouterTest.java (4538, 2008-08-20)
one\test\TestDTNHost.java (1431, 2008-08-20)
one\test\WorldTest.java (2900, 2008-08-20)
one\test\MapBasedMovementTest.java (7466, 2008-08-20)
one\test\AdjacencyGraphvizReportTest.java (2614, 2008-08-20)
one\test\AllTests.java (1809, 2008-08-20)
one\test\ScheduledUpdatesQueueTest.java (3052, 2008-08-20)
one\default_settings.txt (5403, 2008-05-14)
one\WDM_conf_help.txt (1475, 2008-05-14)
one\gui (0, 2008-08-26)
one\gui\SimMenuBar.java (5796, 2008-08-20)
... ...

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 sophisticated version of the map-based movement model (ShortestPathMapBasedMovement) uses Dijkstra's shortest path algorithm to find its way trough the map area. Once a node reaches its destination, and has waited for the pause time, a new random map node is chosen and node moves there using the shortest path that can be taken using only valid map nodes. For the shortest path based movement models, map data can also contain Points Of Interest (POIs). Instead of selecting any random map node for the next destination, the movement model can be configured to give a POI belonging to a certain POI group with a configurable probability. There can be unlimited amount of POI groups and all groups can contain any amount of POIs. All node groups can have different probabilities for all POI groups. POIs can be used to model e.g., shops, restaurants and tourist attractions. Route based movement model (MapRouteMovement) can be used to model nodes that follow certain routes, e.g. bus or tram lines. Only the stops on the route have to be defined and then the nodes using that route move from stop to stop using shortest paths and stop on the stops for the configured time. All movement models can also decide when the node is active (moves and can be connected to) and when not. For all models, except for the external movement, multiple simulation time intervals can be given and the nodes in that group will be active only during those times. All map-based models get their input data using files formatted with a subset of the Well Known Text (WKT) format. LINESTRING and MULTILINESTRING directives of WKT files are supported by the parser for map path data. For point data (e.g. for POIs), also the POINT directive is supported. Adjacent nodes in a (MULTI)LINESTRING are considered to form a path and if some lines contain some vertex(es) with exactly the same coordinates, the paths are joined from those places (this is how you create intersections). WKT files can be edited and generated from real world map data using any suitable Geographic Information System (GIS) program. The map data included in the simulator distribution was converted and edited using the free, Java based OpenJUMP GIS program. Different map types are defined by storing the paths belonging to different types to different files. Points Of Interest are simply defined with WKT POINT directive and POI groups are defined by storing all POIs belonging to a certain group in the same file. All POIs must also be part of the map data so they are accessible using the paths. Stops for the routes are defined with LINESTRING and the stops are traversed in the same order they appear in the LINESTRING. One WKT file can contain multiple routes and they are given to nodes in the same order as they appear in the file. The experimental movement model that uses external movement data (ExternalMovement) reads timestamped node locations from a file and moves the nodes in the simulation accordingly. See javadocs of ExternalMovementReader class from input package for details of the format. A suitable, experimental converter script (transimsParser.pl) for TRANSIMS data is included in the toolkit folder. The movement model to use is defined per node group with the "movementModel" setting. Value of the setting must be a valid movement model class name from the movement package. Settings that are common for all movement models are read in the MovementModel class and movement model specific settings are read in the respective classes. See the javadoc documentation and example configuration files for details. Routing modules and message creation ------------------------------------ Routing modules define how the messages are handled in the simulation. Six different active routing modules (First Contact, Epidemic, Spray and Wait, Direct delivery, PRoPHET and MaxProp) and also a passive router for external routing simulation are included in the package. The active routing modules are implementations of the well known routing algorithms for DTN routing. See the classes in routing package for details. Passive router is made especially for interacting with other (DTN) routing simulators or running simulations that don't need any routing functionality. The router doesn't do anything unless commanded by external events. These external events are provided to the simulator by a class that implements the EventQueue interface. The current release includes two classes that can be used as a source of message events: ExternalEventsQueue and MessageEventGenerator. The former can read events from a file that can be created by hand, with a suitable script (e.g., createCreates.pl script in the toolkit folder), or by converting e.g., dtnsim2's output to suitable form. See StandardEventsReader class from input package for details of the format. MessageEventGenerator is a simple message generator class that creates uniformly distributed message creation patterns with configurable message creation interval, message size and source/destination host ranges. The toolkit folder contains an experimental parser script (dtnsim2parser.pl) for dtnsim2's output (there used to be a more capable Java-based parser but it was discarded in favor of this more easily extendable script). The script requires a few patches to dtnsim2's code and those can be found from the toolkit/dtnsim2patches folder. The routing module to use is defined per node group with the setting "router". All routers can't interact properly (e.g., PRoPHET router can only work with other PRoPHET routers) so usually it makes sense to use the same (or compatible) router for all groups. Reports ------- Reports can be used to create summary data of simulation runs, detailed data of connections and messages, files suitable for post-processing using e.g., Graphviz (to create graphs) and also to interface with other programs. See javadocs of report-package classes for details. There can be any number of reports for any simulation run and the number of reports to load is defined with "Report.nrofReports" setting. Report class names are defined with "Report.reportN" setting, where N is an integer value starting from 1. The values of the settings must be valid report class names from the report package. The output directory of all reports (which can be overridden per report class with the "output" setting) must be defined with Report.reportDir -setting. If no "output" setting is given for a report class, the resulting report file name is "ReportClassName_ScenarioName.txt". All reports have many configurable settings which can be defined using ReportClassName.settingKey -syntax. See javadocs of Report class and specific report classes for details (look for "setting id" definitions). Host groups ----------- A host group is group of hosts (nodes) that shares movement and routing module settings. Different groups can have different values for the settings and this way they can represent different types of nodes. Base settings can be defined in the "Group" namespace and different node groups can override these settings or define new settings in their specific namespaces (Group1, Group2, etc.). The settings ------------ There are plenty of settings to configure; more than is meaningful to present here. See javadocs of especially report, routing and movement model classes for details. See also included settings files for examples. Perhaps the most important settings are the following. Scenario settings: Scenario.name Name of the scenario. All report files are by default prefixed with this. Scenario.simulateConnections Should connections be simulated. If you're only interested in movement modeling, you can disable this to get faster simulation. Usually you want this to be on. Scenario.updateInterval How many seconds are stepped on every update. Increase this to get faster simulation, but then you'll lose some precision. Values from 0.1 to 2 are good for simulations. Scenario.endTime How many simulated seconds to simulate. Scenario.nrofHostGroups How many hosts group are present in the simulation. Host group settings (used in Group or GroupN namespace): groupID Group's identifier (a string or a character). Used as the prefix of host names that are shown in the GUI and reports. Host's full name is groupID+networkAddress. nrofHosts Number of hosts in this group. transmitRange Range (meters) of the hosts' radio devices. transmitSpeed Transmit speed of the hosts' radio devices (bytes per second). movementModel The movement model all hosts in the group use. Must be a valid class (one that is a subclass of MovementModel class) name from the movement package. waitTime Minimum and maximum (two comma-separated decimal values) of the wait time interval (seconds). Defines how long nodes should stay in the same place after reaching the destination of the current path. A new random value within the interval is used on every stop. Default value is 0,0. speed Minimum and maximum (two comma-separated decimal values) of the speed interval (m/s). Defines how fast nodes move. A new random value is used on every new path. Default value is 1,1. bufferSize Size of the nodes' message buffer (bytes). When the buffer is full, node can't accept any more messages unless it drops some old messages from the buffer. router Router module which is used to route messages. Must be a valid class (subclass of Report class) name from routing package. activeTimes Time intervals (comma-separated simulated time value tuples: start1, end1, start2, end2, ...) when the nodes in the group should be active. If no intervals are defined, nodes are active all the time. msgTtl Time To Live (simulated minutes) of the messages created by this host group. Nodes (with active routing module) check every one minute whether some of their messages' TTLs have expired and drop such messages. If no TTL is defined, infinite TTL is used. Group and movement model specific settings (only meaningful for certain movement models): pois Points Of Interest indexes and probabilities (comma-separated index-probability tuples: poiIndex1, poiProb1, poiIndex2, poiProb2, ... ). Indexes are integers and probabilities are decimal values in the range of 0.0-1.0. Setting defines the POI groups where the nodes in this host group can choose destinations from and the probabilities for choosing a certain POI group. For example, a (random) POI from the group defined in the POI file1 (defined with PointsOfInterest.poiFile1 setting) is chosen with the probability poiProb1. If the sum of all probabilities is less than 1.0, a probability of choosing any random map node for the next destination is (1.0 - theSumOfProbabilities). Setting can be used only with ShortestPathMapBasedMovement -based movement models. okMaps Which map node types (refers to map file indexes) are OK for the group (comma-separated list of integers). Nodes will not travel trough map nodes that are not OK for them. As default, all map nodes are OK. Setting can be used with any MapBasedMovent -based movement model. routeFile If MapRouteMovement movement model is used, this setting defines the route file (path) where the route is read from. Route file should contain LINESTRING WKT directives. Each vertex in a LINESTRING represents one stop on the route. routeType If MapRouteMovement movement model is used, this setting defines the routes type. Type can be either circular (valu ... ...

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：