{"id":24511592,"url":"https://github.com/hendrowunga/the-one","last_synced_at":"2025-03-15T09:44:11.203Z","repository":{"id":280425526,"uuid":"921704941","full_name":"hendrowunga/the-one","owner":"hendrowunga","description":"This is my customized fork of  The ONE-Pitt 🛠️, adding features like epidemic delivery analysis 📊, community detection 🕵️‍♂️, and simulation visualization 🎨 to advance opportunistic networking research 🔬.","archived":false,"fork":false,"pushed_at":"2025-03-03T10:34:16.000Z","size":4203,"stargazers_count":0,"open_issues_count":1,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-03-03T11:33:46.377Z","etag":null,"topics":["algorithms-and-data-structures","dtn","simulator"],"latest_commit_sha":null,"homepage":"","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/hendrowunga.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2025-01-24T13:08:58.000Z","updated_at":"2025-03-03T10:34:24.000Z","dependencies_parsed_at":"2025-03-03T11:44:02.591Z","dependency_job_id":null,"html_url":"https://github.com/hendrowunga/the-one","commit_stats":null,"previous_names":["hendrowunga/the-one"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hendrowunga%2Fthe-one","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hendrowunga%2Fthe-one/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hendrowunga%2Fthe-one/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hendrowunga%2Fthe-one/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/hendrowunga","download_url":"https://codeload.github.com/hendrowunga/the-one/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":243713391,"owners_count":20335566,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["algorithms-and-data-structures","dtn","simulator"],"created_at":"2025-01-22T00:38:59.606Z","updated_at":"2025-03-15T09:44:10.946Z","avatar_url":"https://github.com/hendrowunga.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"The ONE v1.4.1 \n=======================\n\nThe ONE is a Opportunistic Network Environment simulator which provides a\npowerful tool for generating mobility traces, running DTN messaging\nsimulations with different routing protocols, and visualizing both\nsimulations interactively in real-time and results after their completion.\n\n\nQuick start\n===========\n\nCompiling\n---------\n\nYou can compile ONE from the source code using the included compile.bat\nscript. That should work both in Windows and Unix/Linux environment with\nJava 6 JDK or later.\n\nIf you want to use Eclipse for compiling the ONE, since version 1.1.0 you need\nto include some jar libraries in the project's build path. The libraries are\nlocated in the lib folder. To include them in Eclipse, assuming that you have\nan Eclipse Java project whose root folder is the folder where you extracted\nthe ONE, do the following:\n\nselect from menus: Project -\u003e Properties -\u003e Java Build Path\nGo to \"Libraries\" tab\nClick \"Add JARs...\"\nSelect \"DTNConsoleConnection.jar\" under the \"lib\" folder\nAdd the \"ECLA.jar\" the same way\nPress \"OK\".\n\nNow Eclipse should be able to compile the ONE without warnings.\n\n\nRunning\n-------\n\nONE can be started using the included one.bat (for Windows) or one.sh (for\nLinux/Unix) script. Following examples assume you're using the Linux/Unix\nscript (just replace \"./one.sh\" with \"one.bat\" for Windows).\n\nSynopsis:\n./one.sh [-b runcount] [conf-files]\n\nOptions:\n-b Run simulation in batch mode. Doesn't start GUI but prints\ninformation about the progress to terminal. The option must be followed\nby the number of runs to perform in the batch mode or by a range of runs\nto perform, delimited with a colon (e.g, value 2:4 would perform runs 2,\n3 and 4). See section \"Run indexing\" for more information.\n\nParameters:  \nconf-files: The configuration file names where simulation parameters\nare read from. Any number of configuration files can be defined and they are\nread in the order given in the command line. Values in the later config files\noverride values in earlier config files.\n\n\nConfiguring\n===========\n\nAll simulation parameters are given using configuration files. These files\nare normal text files that contain key-value pairs. Syntax for most of the\nvariables is:\nNamespace.key = value\n\nI.e., the key is (usually) prefixed by a namespace, followed by a dot, and\nthen key name. Key and value are separated by equals-sign. Namespaces\nstart with capital letter and both namespace and keys are written in\nCamelCase (and are case sensitive). Namespace defines (loosely) the part\nof the simulation environment where the setting has effect on. Many, but\nnot all, namespaces are equal to the class name where they are read.\nEspecially movement models, report modules and routing modules follow this\nconvention.\n\nNumeric values use '.' as the decimal separator and can be suffixed with\nkilo (k) mega (M) or giga (G) suffix. Boolean settings accept \"true\",\n\"false\", \"0\", and \"1\" as values.\n\nMany settings define paths to external data files. The paths can be relative\nor absolute but the directory separator must be '/' in both Unix and Windows\nenvironment.\n\nSome variables contain comma-separated values, and for them the syntax is:\nNamespace.key = value1, value2, value3, etc.\n\nFor run-indexed values the syntax is:\nNamespace.key = [run1value; run2value; run3value; etc]\nI.e., all values are given in brackets and values for different run are\nseparated by semicolon. Each value can also be a comma-separated value.\nFor more information about run indexing, go to section \"Run indexing\".\n\nSetting files can contain comments too. A comment line must start with \"#\"\ncharacter. Rest of the line is skipped when the settings are read. This can\nbe also useful for disabling settings easily.\n\nSome values (scenario and report names at the moment) support \"value\nfilling\". With this feature, you can construct e.g., scenario name\ndynamically from the setting values. This is especially useful when using\nrun indexing. Just put setting key names in the value part prefixed and\nsuffixed by two percent (%) signs. These placeholders are replaces by the\ncurrent setting value from the configuration file. See the included\nsnw_comparison_settings.txt for an example.\n\nFile \"default_settings.txt\", if exists, is always read and the other\nconfiguration files given as parameter can define more settings or override\nsome (or even all) settings in the previous files. The idea is that\nyou can define in the earlier files all the settings that are common for\nall the simulations and run different, specific, simulations using\ndifferent configuration files.\n\n\nRun indexing\n------------ \n\nRun indexing is a feature that allows you to run large amounts of\ndifferent configurations using only single configuration file. The idea is\nthat you provide an array of settings (using the syntax described above)\nfor the variables that should be changed between runs. For example, if you\nwant to run the simulation using five different random number generator\nseeds for movement models, you can define in the settings file the\nfollowing:\n\nMovementModel.rngSeed = [1; 2; 3; 4; 5]\n\nNow, if you run the simulation using command:\n\n./one.sh -b 5 my_config.txt\n\nyou would run first using seed 1 (run index 0), then another run using\nseed 2, etc. Note that you have to run it using batch mode (-b option) if\nyou want to use different values. Without the batch mode flag the first\nparameter (if numeric) is the run index to use when running in GUI mode.\n\nRun indexes wrap around: used value is the value at index (runIndex %\narrayLength). Because of wrapping, you can easily run large amount of\npermutations easily. For example, if you define two key-value pairs:\n\nkey1 = [1; 2]\nkey2 = [a; b; c]\n\nand run simulation using run-index count 6, you would get all permutations\nof the two values (1,a; 2,b; 1,c; 2,a; 1,b; 2,c). This naturally works\nwith any amount of arrays. Just make sure that the smallest common\nnominator of all array sizes is 1 (e.g., use arrays whose sizes are primes)\n-- unless you don't want all permutations but some values should be\npaired.\n\n\nMovement models\n---------------\n\nMovement models govern the way nodes move in the simulation. They provide\ncoordinates, speeds and pause times for the nodes. The basic installation\ncontains 5 movement models: random waypoint, map based movement, shortest\npath map based movement, map route movement and external movement. All\nmodels, except external movement, have configurable speed and pause time\ndistributions. A minimum and maximum values can be given and the movement\nmodel draws uniformly distributed random values that are within the given\nrange. Same applies for pause times. In external movement model the speeds\nand pause times are interpreted from the given data.\n\nWhen a node uses the random waypoint movement model (RandomWaypoint), it is\ngiven a random coordinate in the simulation area. Node moves directly to the\ngiven destination at constant speed, pauses for a while, and then gets a new\ndestination. This continues throughout the simulations and nodes move along\nthese zig-zag paths.\n\nMap-based movement models constrain the node movement to predefined paths.  \nDifferent types of paths can be defined and one can define valid paths for\nall node groups. This way e.g., cars can be prevented from driving indoors or\non pedestrian paths.\n\nThe basic map-based movement model (MapBasedMovement) initially distributes\nthe nodes between any two adjacent (i.e., connected by a path) map nodes and\nthen nodes start moving from adjacent map node to another. When node reaches\nthe next map node, it randomly selects the next adjacent map node but chooses\nthe map node where it came from only if that is the only option (i.e., avoids\ngoing back to where it came from). Once node has moved trough 10-100 map\nnodes, it pauses for a while and then starts moving again.\n\nThe more sophisticated version of the map-based movement model\n(ShortestPathMapBasedMovement) uses Dijkstra's shortest path algorithm to\nfind its way trough the map area. Once a node reaches its destination, and\nhas waited for the pause time, a new random map node is chosen and node moves\nthere using the shortest path that can be taken using only valid map nodes.\n\nFor the shortest path based movement models, map data can also contain Points\nOf Interest (POIs). Instead of selecting any random map node for the next\ndestination, the movement model can be configured to give a POI belonging to\na certain POI group with a configurable probability. There can be unlimited\namount of POI groups and all groups can contain any amount of POIs. All node\ngroups can have different probabilities for all POI groups. POIs can be used\nto model e.g., shops, restaurants and tourist attractions.\n\nRoute based movement model (MapRouteMovement) can be used to model nodes that\nfollow certain routes, e.g. bus or tram lines. Only the stops on the route\nhave to be defined and then the nodes using that route move from stop to stop\nusing shortest paths and stop on the stops for the configured time.\n\nAll movement models can also decide when the node is active (moves and can be\nconnected to) and when not. For all models, except for the external movement,\nmultiple simulation time intervals can be given and the nodes in that group\nwill be active only during those times.\n\nAll map-based models get their input data using files formatted with a subset\nof the Well Known Text (WKT) format. LINESTRING and MULTILINESTRING\ndirectives of WKT files are supported by the parser for map path data. For\npoint data (e.g. for POIs), also the POINT directive is supported. Adjacent\nnodes in a (MULTI)LINESTRING are considered to form a path and if some lines\ncontain some vertex(es) with exactly the same coordinates, the paths are\njoined from those places (this is how you create intersections). WKT files\ncan be edited and generated from real world map data using any suitable\nGeographic Information System (GIS) program. The map data included in the\nsimulator distribution was converted and edited using the free, Java based\nOpenJUMP GIS program.\n\nDifferent map types are defined by storing the paths belonging to different\ntypes to different files. Points Of Interest are simply defined with WKT\nPOINT directive and POI groups are defined by storing all POIs belonging to a\ncertain group in the same file. All POIs must also be part of the map data so\nthey are accessible using the paths. Stops for the routes are defined with\nLINESTRING and the stops are traversed in the same order they appear in the\nLINESTRING. One WKT file can contain multiple routes and they are given to\nnodes in the same order as they appear in the file.\n\nThe experimental movement model that uses external movement data\n(ExternalMovement) reads timestamped node locations from a file and moves the\nnodes in the simulation accordingly. See javadocs of ExternalMovementReader\nclass from input package for details of the format. A suitable, experimental\nconverter script (transimsParser.pl) for TRANSIMS data is included in the\ntoolkit folder.\n\nThe movement model to use is defined per node group with the \"movementModel\"\nsetting. Value of the setting must be a valid movement model class name from\nthe movement package. Settings that are common for all movement models are\nread in the MovementModel class and movement model specific settings are read\nin the respective classes. See the javadoc documentation and example\nconfiguration files for details.\n\nRouting modules and message creation\n------------------------------------\n\nRouting modules define how the messages are handled in the simulation. Six\ndifferent active routing modules (First Contact, Epidemic, Spray and Wait,\nDirect delivery, PRoPHET and MaxProp) and also a passive router for external\nrouting simulation are included in the package. The active routing modules are\nimplementations of the well known routing algorithms for DTN routing. See the\nclasses in routing package for details.\n\nPassive router is made especially for interacting with other (DTN) routing\nsimulators or running simulations that don't need any routing functionality.\nThe router doesn't do anything unless commanded by external events. These\nexternal events are provided to the simulator by a class that implements the\nEventQueue interface.\n\nThe current release includes two classes that can be used as a source of\nmessage events: ExternalEventsQueue and MessageEventGenerator. The former\ncan read events from a file that can be created by hand, with a suitable\nscript (e.g., createCreates.pl script in the toolkit folder), or by\nconverting e.g., dtnsim2's output to suitable form. See StandardEventsReader\nclass from input package for details of the format. MessageEventGenerator is\na simple message generator class that creates uniformly distributed message\ncreation patterns with configurable message creation interval, message size\nand source/destination host ranges.\n\nThe toolkit folder contains an experimental parser script (dtnsim2parser.pl)\nfor dtnsim2's output (there used to be a more capable Java-based parser but\nit was discarded in favor of this more easily extendable script). The script\nrequires a few patches to dtnsim2's code and those can be found from the\ntoolkit/dtnsim2patches folder.\n\nThe routing module to use is defined per node group with the setting\n\"router\". All routers can't interact properly (e.g., PRoPHET router can only\nwork with other PRoPHET routers) so usually it makes sense to use the same\n(or compatible) router for all groups.\n\nReports\n-------\n\nReports can be used to create summary data of simulation runs, detailed data\nof connections and messages, files suitable for post-processing using e.g.,\nGraphviz (to create graphs) and also to interface with other programs. See\njavadocs of report-package classes for details.\n\nThere can be any number of reports for any simulation run and the number of\nreports to load is defined with \"Report.nrofReports\" setting. Report class\nnames are defined with \"Report.reportN\" setting, where N is an integer value\nstarting from 1. The values of the settings must be valid report class names\nfrom the report package. The output directory of all reports (which can be\noverridden per report class with the \"output\" setting) must be defined with\nReport.reportDir -setting. If no \"output\" setting is given for a report\nclass, the resulting report file name is \"ReportClassName_ScenarioName.txt\".\n\nAll reports have many configurable settings which can be defined using\nReportClassName.settingKey -syntax. See javadocs of Report class and specific\nreport classes for details (look for \"setting id\" definitions).\n\nHost groups\n-----------\n\nA host group is group of hosts (nodes) that shares movement and routing\nmodule settings. Different groups can have different values for the settings\nand this way they can represent different types of nodes. Base settings can\nbe defined in the \"Group\" namespace and different node groups can override\nthese settings or define new settings in their specific namespaces (Group1,\nGroup2, etc.).\n\nThe settings\n------------\n\nThere are plenty of settings to configure; more than is meaningful to\npresent here. See javadocs of especially report, routing and movement\nmodel classes for details. See also included settings files for examples.\nPerhaps the most important settings are the following.\n\n\nScenario settings:\n---\n\nScenario.name\nName of the scenario. All report files are by default prefixed with this.\n\nScenario.simulateConnections\nShould connections be simulated. If you're only interested in movement\nmodeling, you can disable this to get faster simulation. Usually you want\nthis to be on.\n\nScenario.updateInterval\nHow many seconds are stepped on every update. Increase this to get faster\nsimulation, but then you'll lose some precision. Values from 0.1 to 2 are good\nfor simulations.\n\nScenario.endTime\nHow many simulated seconds to simulate.\n\nScenario.nrofHostGroups\nHow many hosts group are present in the simulation.\n\nInterface settings (used to define the possible interfaces the nodes can have)\n---\n\ntype\nWhat class (from the interfaces-directory) is used for this interface\n\nThe remaining settings are class-specific.  Can be for example:\n\ntransmitRange\nRange (meters) of the interface.\n\ntransmitSpeed\nTransmit speed of the interface (bytes per second).\n\nHost group settings (used in Group or GroupN namespace):\n---\n\ngroupID\nGroup's identifier (a string or a character). Used as the prefix of host\nnames that are shown in the GUI and reports. Host's full name is\ngroupID+networkAddress.\n\nnrofHosts\nNumber of hosts in this group.\n\nnrofInterfaces\nNumber of interfaces this the nodes of this group use\n\ninterfaceX\nThe interface that should be used as the interface number X\n\nmovementModel\nThe movement model all hosts in the group use. Must be a valid class (one\nthat is a subclass of MovementModel class) name from the movement package.\n\nwaitTime\nMinimum and maximum (two comma-separated decimal values) of the wait time\ninterval (seconds). Defines how long nodes should stay in the same place\nafter reaching the destination of the current path. A new random value within\nthe interval is used on every stop. Default value is 0,0.\n\nspeed\nMinimum and maximum (two comma-separated decimal values) of the speed\ninterval (m/s). Defines how fast nodes move. A new random value is used on\nevery new path. Default value is 1,1.\n\nbufferSize\nSize of the nodes' message buffer (bytes). When the buffer is full, node can't\naccept any more messages unless it drops some old messages from the buffer.\n\nrouter\nRouter module which is used to route messages. Must be a valid class\n(subclass of Report class) name from routing package.\n\nactiveTimes\nTime intervals (comma-separated simulated time value tuples: start1, end1,\nstart2, end2, ...) when the nodes in the group should be active. If no\nintervals are defined, nodes are active all the time.\n\nmsgTtl\nTime To Live (simulated minutes) of the messages created by this host group.  \nNodes (with active routing module) check every one minute whether some of\ntheir messages' TTLs have expired and drop such messages. If no TTL is\ndefined, infinite TTL is used.\n\n\nGroup and movement model specific settings (only meaningful for certain\nmovement models):\n\npois\nPoints Of Interest indexes and probabilities (comma-separated\nindex-probability tuples: poiIndex1, poiProb1, poiIndex2, poiProb2, ... ).\nIndexes are integers and probabilities are decimal values in the range of\n0.0-1.0. Setting defines the POI groups where the nodes in this host group\ncan choose destinations from and the probabilities for choosing a certain POI\ngroup. For example, a (random) POI from the group defined in the POI file1\n(defined with PointsOfInterest.poiFile1 setting) is chosen with the\nprobability poiProb1. If the sum of all probabilities is less than 1.0, a\nprobability of choosing any random map node for the next destination is (1.0\n- theSumOfProbabilities). Setting can be used only with\n  ShortestPathMapBasedMovement -based movement models.\n\nokMaps\nWhich map node types (refers to map file indexes) are OK for the group\n(comma-separated list of integers).  Nodes will not travel trough map nodes\nthat are not OK for them. As default, all map nodes are OK. Setting can be\nused with any MapBasedMovent -based movement model.\n\nrouteFile\nIf MapRouteMovement movement model is used, this setting defines the route\nfile (path) where the route is read from. Route file should contain\nLINESTRING WKT directives. Each vertex in a LINESTRING represents one stop\non the route.\n\nrouteType\nIf MapRouteMovement movement model is used, this setting defines the routes\ntype. Type can be either circular (value 1) or ping-pong (value 2). See\nmovement.map.MapRoute class for details.\n\n\nMovement model settings:\n---\n\nMovementModel.rngSeed\nThe seed for all movement models' random number generator. If the seed and\nall the movement model related settings are kept the same, all nodes should\nmove the same way in different simulations (same destinations and speed \u0026\nwait time values are used).\n\nMovementModel.worldSize\nSize of the simulation world in meters (two comma separated values:\nwidth, height).\n\nPointsOfInterest.poiFileN\nFor ShortestPathMapBasedMovement -based movement models, this setting defines\nthe WKT files where the POI coordinates are read from. POI coordinates are\ndefined using the POINT WKT directive. The \"N\" in the end of the setting must\nbe a positive integer (i.e., poiFile1, poiFile2, ...).\n\nMapBasedMovement.nrofMapFiles\nHow many map file settings to look for in the settings file.\n\nMapBasedMovement.mapFileN\nPath to the Nth map file (\"N\" must be a positive integer). There must be at\nleast nrofMapFiles separate files defined in the configuration files(s). All\nmap files must be WKT files with LINESTRING and/or MULTILINESTRING WKT\ndirectives. Map files can contain POINT directives too, but those are\nskipped. This way the same file(s) can be used for both POI and map data. By\ndefault the map coordinates are translated so that the upper left corner of\nthe map is at coordinate point (0,0). Y-coordinates are mirrored before\ntranslation so that the map's north points up in the playfield view. Also all\nPOI and route files are translated to match to the map data transformation.\n\n\nReport settings:\n---\n\nReport.nrofReports\nHow many report modules to load. Module names are defined with settings\n\"Report.report1\", \"Report.report2\", etc. Following report settings can be\ndefined for all reports (using Report name space) or just for certain reports\n(using ReportN name spaces).\n\nReport.reportDir\nWhere to store the report output files. Can be absolute path or relative to\nthe path where the simulation was started. If the directory doesn't exists,\nit is created.\n\nReport.warmup\nLength of the warm up period (simulated seconds from the start). During the\nwarm up the report modules should discard the new events. The behavior is\nreport module specific so check the (java)documentation of different report\nmodules for details.\n\n\nEvent generator settings:\n---\n\nEvents.nrof\nHow many event generators are loaded for the simulation. Event generator\nspecific settings (see below) are defined in EventsN namespaces (so\nEvents1.settingName configures a setting for the 1st event generator etc.).\n\nEventsN.class\nName of the generator class to load (e.g., ExternalEventsQueue or\nMessageEventGenerator). The class must be found from the input package.\n\nFor the ExternalEventsQueue you must at least define the path to the external\nevents file (using setting \"filePath\"). See input.StandardEventsReader class'\njavadocs for information about different external events.\n\n\nOther settings:\n---\n\nOptimization.randomizeUpdateOrder\nShould the order in which the nodes' update method is called be randomized.\nCall to update causes the nodes to check their connections and also update\ntheir routing module. If set to false, node update order is the same as their\nnetwork address order. With randomizing, the order is different on every time\nstep.\n\n\n\nGUI\n===\n\nThe GUI's main window is divided into three parts. The main part contains\nthe playfield view (where node movement is displayed) and simulation and\nGUI control and information. The right part is used to select nodes and\nthe lower part is for logging and breakpoints.\n\nThe main part's topmost section is for simulation and GUI controls. The\nfirst field shows the current simulation time. Next field shows the\nsimulation speed (simulated seconds per second). The following four\nbuttons are used to pause, step, fast forward, and fast forward simulation\nto given time. Pressing step-button multiple times runs simulation\nstep-by-step. Fast forward (FFW) can be used to skip uninteresting parts\nof simulation. In FFW, the GUI update speed is set to a large value. Next\ndrop-down is used to control GUI update speed. Speed 1 means that GUI is\nupdated on every simulated second. Speed 10 means that GUI is updated only\non every 10th second etc. Negative values slow down the simulation. The\nfollowing drop-down controls the zoom factor. The last button saves the\ncurrent view as a png-image.\n\nMiddle section, i.e., the playfield view, shows the node placement, map\npaths, node identifiers, connections among nodes etc. All nodes are\ndisplayed as small rectangles and their radio range is shown as a green\ncircle around the node. Node's group identifier and network address (a\nnumber) are shown next to each node. If a node is carrying messages, each\nmessage is represented by a green or blue filled rectangle. If node\ncarries more than 10 messages, another column of rectangles is drawn for\neach 10 messages but every other rectangle is now red. You can center the\nview to any place by clicking with mouse button on the play field. Zoom\nfactor can also be changed using mouse wheel on top of the playfield view.\n\nThe right part of main window is for choosing a node for closer inspection.\nSimply clicking a button shows the node info in main parts lower section.\nFrom there more information can be displayed by selecting one of the\nmessages the node is carrying (if any) from the drop-down menu. Pressing\nthe \"routing info\" button opens a new window where information about the\nrouting module is displayed. When a node is chosen, the playfield view is\nalso centered on that node and the current path the node is traveling is\nshown in red.\n\nLogging (the lowest part) if divided to two sections, control and log. From\nthe control part you can select what kind of messages are shown in the\nlog. You can also define if simulation should be paused on certain type of\nevent (using the check boxes in the \"pause\" column). Log part displays time\nstamped events. All nodes and message names in the log messages are\nbuttons and you can get more information about them by clicking the\nbuttons.\n\nDTN2 Reference Implementation Connectivity\n==========================================\n\nDTN2 connectivity allows bundles to be passed between the ONE and any\nnumber of DTN2 routers. This is done through DTN2's External Convergence\nLayer Interface.\n\nWhen DTN2 connectivity is enabled ONE will connect to dtnd routers as\nan external convergence layer adapter. ONE will also automatically configure\ndtnd through a console connection with a link and route for bundles to reach\nthe simulator.\n\nWhen a bundle is received from dtnd, ONE attempts to match the destination EID\nagainst the regular expressions configured in the configuration file (see DTN2\nConnectivity Configuration File below). For each matching node a copy of a\nmessage is created and routed inside ONE. When the bundle reaches its destination\ninside ONE it is delivered to the dtnd router instance attached to the node.\nCopies of the bundle payload are stored within 'bundles' directory.\n\nTo enable this functionality the following steps must be taken:\n\n1) DTN2 must be compiled and configured with ECL support enabled.\n2) DTN2Events event generator must be configured to be loaded into ONE\n   as an events class.\n3) DTN2Reporter must be configured and loaded into one as a report class.\n4) DTN2 connectivity configuration file must be configured as DTN2.configFile\n\nTo start the simulation:\n1) Start all the dtnd router instances.\n2) Start ONE.\n\nExample Configuration (2-4 above)\n---------------------------------\n\nEvents.nrof = 1\nEvents1.class = DTN2Events\nReport.nrofReports = 1\nReport.report1 = DTN2Reporter\nDTN2.configFile = cla.conf\n\nDTN2 Connectivity Configuration File\n------------------------------------\n\nThe DTN2 connectivity configuration file defines which nodes inside ONE\nshould connect to which DTN2 router instances. It also defines the EID's\nthat the nodes match.\n\nThe configuration file is composed of comment lines starting with # and\nconfiguration lines with the following format:\n\n\u003cnodeID\u003e \u003cEID regexp\u003e \u003cdtnd host\u003e \u003cECL port\u003e \u003cconsole port\u003e\n\nThe fields have the following meaning:\n\nnodeID:\t\tThe ID of a node inside ONE (integer \u003e= 0)\nEID regexp:\tIncoming bundles whose destination EID matches this regexp\nwill be forwarded to the node inside ONE.\n(see java.util.regex.Pattern)\ndtnd host:\tHostname/IP of the dtnd router to connect to this node.\nECL port:\tdtnd router's port listening to ECLAs\nconsole port:\tdtnd router's console port\n\nExample:\n# \u003cnodeID\u003e \u003cEID regexp\u003e \u003cdtnd host\u003e \u003cECL port\u003e \u003cconsole port\u003e\n1 dtn://local-1.dtn/(.*) localhost 8801 5051\n2 dtn://local-2.dtn/(.*) localhost 8802 5052\n\nKnown Issues\n------------\n\nFor DTN2 connectivity related issues, you can contact teemuk@netlab.tkk.fi\n\n-Quitting dtnd router instances connected to ONE will cause ONE to quit.\n\nToolkit\n=======\n\nThe simulation package includes a folder called \"toolkit\" that contains\nscripts for generating input and processing the output of the simulator. All\n(currently included) scripts are written with Perl (http://www.perl.com/) so\nyou need to have it installed before running the scripts. Some post processing\nscripts use gnuplot (http://www.gnuplot.info/) for creating graphics. Both of\nthe programs are freely available for most of the Unix/Linux and Windows\nenvironments. For Windows environment, you may need to change the path to the\nexecutables for some of the scripts.\n\ngetStats.pl\nThis script can be used to create bar-plots of various statistics gathered by\nthe MessageStatsReport -report module. The only mandatory option is \"-stat\"\nwhich is used to define the name of the statistics value that should be parsed\nfrom the report files (e.g., \"delivery_prob\" for message delivery\nprobabilities). Rest of the parameters should be MessageStatsReport output\nfilenames (or paths). Script creates three output files: one with values from\nall the files, one with the gnuplot commands used to create the graphics and\nfinally an image file containing the graphics. One bar is created to the plot\nfor each input file. The title for each bar is parsed from the report filename\nusing the regular expression defined with \"-label\" option. Run getStats.pl\nwith \"-help\" option for more help.\n\nccdfPlotter.pl\nScript for creating Complementary(/Inverse) Cumulative Distribution Function\nplots (using gluplot) from reports that contain time-hitcount-tuples. Output\nfilename must be defined with the \"-out\" option and rest of the parameters\nshould be (suitable) report filenames. \"-label\" option can be used for\ndefining label extracting regular expression (similar to one for the getStats\nscript) for the legend.\n\ncreateCreates.pl\nMessage creation pattern for the simulation can be defined with external events\nfile. Such a file can be simply created with any text editor but this script\nmakes it easier to create a large amount of messages. Mandatory options are\nthe number of messages (\"-nrof\"), time range (\"-time\"), host address range\n(\"-hosts\") and message size range (\"-sizes\"). The number of messages is simply\nan integer but the ranges are given with two integers with a colon (:) between\nthem. If hosts should reply to the messages that they receive, size range of\nthe reply messages can be defined with \"-rsizes\" option. If a certain random\nnumber generator seed should be used, that can be defined with \"-seed\" option.\nAll random values are drawn from a uniform distribution with inclusive minimum\nvalue and exclusive maximum value. Script outputs commands that are suitable\nfor external events file's contents. You probably want to redirect the output\nto some file.\n\ndtnsim2parser.pl and transimsParser.pl\nThese two (quite experimental) parsers convert data from other programs to a\nform that is suitable for ONE. Both take two parameters: input and output\nfile. If these parameters are omitted, stdin and stdout are used for input and\noutput. With \"-h\" option a short help is printed.\ndtnsim2parser converts dtnsim2's (http://watwire.uwaterloo.ca/DTN/sim/) output\n(with verbose mode 8) to an external events file that can be fed to ONE. The\nmain idea of this parser is that you can first create a connectivity pattern\nfile using ONE and ConnectivityDtnsim2Report, feed that to dtnsim2 and then\nobserve the results visually in ONE (using the output converted with\ndtnsim2parser as the external events file).\ntransimsParser can convert TRANSIM's (http://transims-opensource.net/) vehicle\nsnapshot files to external movement files that can be used as an input for\nnode movement. See ExternalMovement and ExternalMovementReader classes for\nmore information.","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fhendrowunga%2Fthe-one","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fhendrowunga%2Fthe-one","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fhendrowunga%2Fthe-one/lists"}