(Motivations)
 
(13 versioni intermedie di 2 utenti non mostrate)
Riga 1: Riga 1:
<accesscontrol>Lab</accesscontrol>
+
=TestNet Framework=
= TestNet Framework (a.k.a. NS-2 for the real world)=
 
The framework will be basically built upon the following entities:
 
 
 
* Nodes
 
* Experiment Managers
 
* Services
 
  
 
== Motivations==
 
== Motivations==
The motivation of TNF is to have a set of tools that will enable to deploy real network experiments in a simple and automated way without the knowledge of how Services work and minimizing the time required for distributed testbeds set up.
+
TNF is a framework made by a set of tools that allows to deploy real network experiments in a simple and automated way while minimizing the time required for distributed testbeds set up.
  
Another motivation for the TNF is that at the time of writing there is no tool that is able to display results of networking experiments, because of the different log files format used by each application.
+
A distributed database maintains the informations about topology, experiment settings and logfiles obtained in the experiments. Therefore, all log files involved in the experiments, and distributed among the nodes, can be retrieved in a transparent manner ("just a button click") using a simple API call made available by the framework.  
  
 +
An overlay Peer-to-Peer network is used for setting up experiments: all nodes involved in an experiment may contact a central node (the supernode) where information about the topology of the overlay network are stored.
 +
A ''Service Discovery'' system will help the researcher to find services which he needs for his experiments.
  
 
==Definitions==
 
==Definitions==
 +
The framework will be basically built upon the following entities:
 +
 +
* Nodes
 +
* Experiment Managers
 +
* Services
  
 
An '''experiment''' involves a set of '''Nodes''' or hosts running a set of '''Services''' or, in the NS-2 jargon, sinks/agents.<br/>
 
An '''experiment''' involves a set of '''Nodes''' or hosts running a set of '''Services''' or, in the NS-2 jargon, sinks/agents.<br/>
 
In the TestNet Framework (TNF) an experiment is defined as ''"the interaction between services of different Nodes or within a single Node under the control of a special Node which is called '''Experiment Manager''"'''.
 
In the TestNet Framework (TNF) an experiment is defined as ''"the interaction between services of different Nodes or within a single Node under the control of a special Node which is called '''Experiment Manager''"'''.
  
Each service produces logfiles in order to evaluate performances indexes so that the Experiment Manager will have at the end of the experiment all logfiles produced by each nodes involved in the experiment.
+
Each service produces logfiles in order to evaluate performances indexes so that the Experiment Manager will store all logfiles produced by each nodes involved in the experiment.
  
 
The TestNet Framework is built upon the following tools:
 
The TestNet Framework is built upon the following tools:
Riga 26: Riga 27:
 
* Node Monitor
 
* Node Monitor
  
The ''Testnet Overlay Network'' (TON) is a network built on Node Monitors which communicates between each other using the RPC protocol.
+
The ''Testnet Overlay Network'' (TON) is a network built on Node Monitors which communicate between them using the RPC protocol.
  
 
The ''Node Monitor'' (NM) manages services available on the node itself and executes commands received via the RPC interface sent by other nodes in the overlay network.
 
The ''Node Monitor'' (NM) manages services available on the node itself and executes commands received via the RPC interface sent by other nodes in the overlay network.
Riga 32: Riga 33:
 
The ''Experiment Manager'' (EM) runs distributed experiments making basically RPC calls to NMs using a simple scripting language. Moreover EM can ask NMs services available on the node in order to search for specific services in the overlay network.
 
The ''Experiment Manager'' (EM) runs distributed experiments making basically RPC calls to NMs using a simple scripting language. Moreover EM can ask NMs services available on the node in order to search for specific services in the overlay network.
  
''Services'' are the core of the framework, they have to export an interface for logging (LogI) facilities and to manage start/stop of the service. We can define a service as ''any piece of software that exports those two interfaces'' to the node manager. The NM communicate to each service via the DBUS inter process communication (IPC) facility.
+
''Services'' are the core of the framework, they have to export an interface for logging (LogI) facilities and to manage start/stop of the service. We can define a service as ''any piece of software that exports those two interfaces'' to the node manager. The NM communicate to each service via the [http://www.freedesktop.org/wiki/Software/dbus DBUS] inter process communication (IPC) facility.
 +
 
 +
Applications that use [[ Libnetmeas | libnetmeas]] automatically export the Logging Interface so the only other requirement to let the application be in the framework is to write a simple wrapper that implements the start/stop interface.
 +
 
 +
[[Immagine:testnet_big_picture.png]]

Versione attuale delle 17:16, 9 Giu 2009

TestNet Framework

Motivations

TNF is a framework made by a set of tools that allows to deploy real network experiments in a simple and automated way while minimizing the time required for distributed testbeds set up.

A distributed database maintains the informations about topology, experiment settings and logfiles obtained in the experiments. Therefore, all log files involved in the experiments, and distributed among the nodes, can be retrieved in a transparent manner ("just a button click") using a simple API call made available by the framework.

An overlay Peer-to-Peer network is used for setting up experiments: all nodes involved in an experiment may contact a central node (the supernode) where information about the topology of the overlay network are stored. A Service Discovery system will help the researcher to find services which he needs for his experiments.

Definitions

The framework will be basically built upon the following entities:

  • Nodes
  • Experiment Managers
  • Services

An experiment involves a set of Nodes or hosts running a set of Services or, in the NS-2 jargon, sinks/agents.
In the TestNet Framework (TNF) an experiment is defined as "the interaction between services of different Nodes or within a single Node under the control of a special Node which is called Experiment Manager".

Each service produces logfiles in order to evaluate performances indexes so that the Experiment Manager will store all logfiles produced by each nodes involved in the experiment.

The TestNet Framework is built upon the following tools:

  • Library for Network Measurements (libnetmeas)
  • Network Log Plot (Nlp)
  • Experiment Manager
  • Node Monitor

The Testnet Overlay Network (TON) is a network built on Node Monitors which communicate between them using the RPC protocol.

The Node Monitor (NM) manages services available on the node itself and executes commands received via the RPC interface sent by other nodes in the overlay network.

The Experiment Manager (EM) runs distributed experiments making basically RPC calls to NMs using a simple scripting language. Moreover EM can ask NMs services available on the node in order to search for specific services in the overlay network.

Services are the core of the framework, they have to export an interface for logging (LogI) facilities and to manage start/stop of the service. We can define a service as any piece of software that exports those two interfaces to the node manager. The NM communicate to each service via the DBUS inter process communication (IPC) facility.

Applications that use libnetmeas automatically export the Logging Interface so the only other requirement to let the application be in the framework is to write a simple wrapper that implements the start/stop interface.

Testnet big picture.png

Exception encountered, of type "TypeError"
[d47345ff78be5b5b627f9854] /index.php?title=TestnetFramework&diff=3744&oldid=2048 TypeError from line 82 of /var/lib/mediawiki/includes/page/Article.php: Argument 1 passed to Article::__construct() must be an instance of Title, string given, called in /var/lib/mediawiki/extensions/accesscontrol.php on line 85
Backtrace:
#0 /var/lib/mediawiki/extensions/accesscontrol.php(85): Article->__construct(string, integer)
#1 /var/lib/mediawiki/includes/parser/Parser.php(4279): controlUserAccess(string, array, Parser, PPFrame_DOM)
#2 /var/lib/mediawiki/includes/parser/Preprocessor_DOM.php(1260): Parser->extensionSubstitution(array, PPFrame_DOM)
#3 /var/lib/mediawiki/includes/parser/Parser.php(3380): PPFrame_DOM->expand(DOMElement, integer)
#4 /var/lib/mediawiki/includes/parser/Parser.php(1261): Parser->replaceVariables(string)
#5 /var/lib/mediawiki/includes/parser/Parser.php(452): Parser->internalParse(string)
#6 /var/lib/mediawiki/skins/bootstrap-mediawiki/BootstrapMediaWiki.skin.php(495): Parser->parse(string, Title, ParserOptions)
#7 /var/lib/mediawiki/skins/bootstrap-mediawiki/BootstrapMediaWiki.skin.php(244): BootstrapMediaWikiTemplate->includePage(string)
#8 /var/lib/mediawiki/includes/skins/SkinTemplate.php(248): BootstrapMediaWikiTemplate->execute()
#9 /var/lib/mediawiki/includes/OutputPage.php(2335): SkinTemplate->outputPage()
#10 /var/lib/mediawiki/includes/MediaWiki.php(743): OutputPage->output()
#11 /var/lib/mediawiki/includes/MediaWiki.php(509): MediaWiki->main()
#12 /var/lib/mediawiki/index.php(43): MediaWiki->run()
#13 {main}