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.
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. In spite of this, we aim at providing tools to produce homogeneous logfiles for each application involved in the experiments.
A distributed database maintains the informations about topology, experiment settings and logfiles obtained by the experiments. In this way it is possibile to deploy a system which is able to retrieve in a transparent manner ("just a button click") all log files involved in an experiments which are obviously distributed among all the nodes.
An overlay Peer-to-Peer network is used for setting up experiments: all nodes which would like to set up an experiment can contact a central node (the supernode) which has informations about the topology of the overlay network. A Service Discovery system will help the researcher to find services which he needs for his experiments.
The framework will be basically built upon the following entities:
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 have at the end of the experiment all logfiles produced by each nodes involved in the experiment.
The TestNet Framework is built upon the following tools:
The Testnet Overlay Network (TON) is a network built on Node Monitors which communicates between each other 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.
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.
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. In spite of this, we aim at providing tools to produce homogeneous logfiles for each application involved in the experiments.
A distributed database maintains the informations about topology, experiment settings and logfiles obtained by the experiments. In this way it is possibile to deploy a system which is able to retrieve in a transparent manner ("just a button click") all log files involved in an experiments which are obviously distributed among all the nodes.
An overlay Peer-to-Peer network is used for setting up experiments: all nodes which would like to set up an experiment can contact a central node (the supernode) which has informations about the topology of the overlay network. A Service Discovery system will help the researcher to find services which he needs for his experiments.
The framework will be basically built upon the following entities:
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 have at the end of the experiment all logfiles produced by each nodes involved in the experiment.
The TestNet Framework is built upon the following tools:
The Testnet Overlay Network (TON) is a network built on Node Monitors which communicates between each other 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.