Manuel de simulation de réseau ns-3. Chapitre 4

chapitres 1,2
chapitre 3

4 Aperçu du concept
4.1 Abstractions clés
4.1.1 Node (Nœud)
4.1.2 Application (Application)
4.1.3 Channel (Canal)
4.1.4 Net Device (Dispositif réseau)
4.1.5 Assistants topologiques
4.2 Premier script ns-3
4.2.1 Code boilerplate
4.2.2 Modules connectés
4.2.3 Espace de noms ns3
4.2.4 Journalisation
4.2.5 Fonction principale
4.2.6 Utilisation des assistants topologiques
4.2.7 Utilisation de l'Application
4.2.8 Simulateur
4.2.9 Assemblage de votre scénario
4.3 Code source de ns-3

Chapitre 4

Aperçu du concept

La première chose que nous devons faire avant de commencer à étudier ou à écrire du code ns-3 est d'expliquer quelques concepts fondamentaux et abstractions dans le système. Beaucoup d'entre eux peuvent sembler évidents pour certains, mais nous vous recommandons de prendre le temps de lire cette section pour vous assurer que vous commencez sur une base solide.

4.1 Abstractions clés

Dans cette section, nous examinerons certains termes qui sont généralement utilisés dans le réseau, mais qui ont une signification particulière dans ns-3.

4.1.1 Node (Nœud)

Dans le jargon Internet, un dispositif informatique qui se connecte au réseau est appelé un hôte ou parfois un système terminal. Pour cette raison, étant donné que ns-3 est un simulateur de réseau et non un simulateur Internet, nous évitons délibérément d'utiliser le terme hôte, car il est étroitement lié à Internet et à ses protocoles. À la place, nous utilisons un terme plus général, également utilisé par d'autres simulateurs, qui trouve son origine dans la théorie des graphes : nœud (node).

Dans ns-3, l'abstraction de base d'un dispositif informatique est appelée nœud. Cette abstraction est représentée en C++ par la classe Node. La classe NodeNode (nœud) fournit des méthodes pour gérer les représentations des dispositifs informatiques dans les simulations.

Vous devez comprendre Nœud comme un ordinateur auquel vous ajouterez des fonctionnalités. Vous ajoutez des choses telles que des applications, des piles de protocoles et des cartes d'extension avec des pilotes, permettant à l'ordinateur d'effectuer un travail utile. Nous utilisons le même modèle de base dans ns-3.

4.1.2 Application (Application)

En général, les logiciels informatiques se divisent en deux grandes catégories. Les logiciels système organisent diverses ressources informatiques telles que la mémoire, les cycles du processeur, le disque, le réseau, etc., selon un certain modèle de calcul. Les logiciels système n'utilisent généralement pas ces ressources pour effectuer des tâches qui apportent un bénéfice direct à l'utilisateur. Pour atteindre un objectif spécifique, l'utilisateur lance généralement une application qui obtient et utilise les ressources contrôlées par le logiciel système.

Souvent, la ligne de séparation entre le logiciel système et le logiciel applicatif se trace au niveau du changement de privilèges qui se produit dans les appels systèmes. Dans ns‑3, il n'y a pas de véritable concept de système d'exploitation et donc pas de notions de niveaux de privilèges ou d'appels système. Cependant, nous avons l'idée d'application. Tout comme dans le "monde réel", pour accomplir des tâches, les applications fonctionnent sur des ordinateurs, les applications ns‑3 fonctionnent sur les nœuds ns‑3 pour gérer les simulations dans un monde simulé.

Dans ns‑3, l'abstraction de base pour un programme utilisateur qui génère une certaine activité pour la modélisation est l'application. Cette abstraction est représentée en C++ par la classe Application. La classe Application fournit des méthodes pour gérer dans les simulations les représentations de notre version des applications de niveau utilisateur. Il est attendu des développeurs qu'ils spécialisent la classe Application pour créer de nouvelles applications dans un sens orienté objet. Dans ce guide, nous utiliserons les spécialisations de la classe Application, appelées UdpEchoClientApplication et UdpEchoServerApplication. Comme il fallait s'y attendre, ces applications constituent un ensemble d'applications client/serveur utilisées pour générer et simuler des paquets réseau en écho.

4.1.3 Channel (Canal)

Dans le monde réel, un ordinateur peut être connecté à un réseau. Souvent, les milieux par lesquels les données sont transmises dans ces réseaux sont appelés des canaux. Lorsque vous connectez un câble Ethernet à une prise murale, vous connectez l'ordinateur à un canal de communication Ethernet. Dans le monde simulé de ns‑3, un nœud est connecté à un objet représentant un canal de communication. Ici, la principale abstraction de la sous-réseau de communication est appelée canal et est représentée dans C++ par la classe Channel.

Classe ChannelChannel fournit des méthodes pour gérer l'interaction des objets de sous-réseau et leur connexion à des nœuds. Les canaux peuvent également être spécialisés par les développeurs en termes de programmation orientée objet. La spécialisation d'un canal peut modéliser quelque chose d'aussi simple qu'un fil. Un canal spécialisé peut également modéliser des choses complexes comme un grand commutateur Ethernet ou un espace tridimensionnel rempli d'obstacles dans le cas des réseaux sans fil.

Nous allons utiliser dans ce guide des versions spécialisées de canal appelées CsmaChannelCsmaChannel, PointToPointChannelPointToPointChannel et WifiChannelWifiChannel. CsmaChannel, par exemple, modélise une version de la sous-réseau de communication qui implémente un environnement de communication à accès multiple avec contrôle de porteuse. Cela nous donne une fonctionnalité similaire à celle de l'Ethernet.

4.1.4 Net Device (Dispositif réseau)

Auparavant, si vous vouliez connecter un ordinateur à un réseau, vous deviez acheter un câble réseau spécifique et un dispositif matériel appelé (dans le jargon PC) carte d'extension, qui devait être installée dans l'ordinateur. Si certaines fonctions réseau étaient implémentées sur la carte d'extension, elles étaient appelées cartes d'interface réseau ou cartes réseau. Aujourd'hui, la plupart des ordinateurs sont équipés de matériel d'interface réseau intégré, et les utilisateurs ne les considèrent pas comme des dispositifs séparés.

Une carte réseau ne fonctionnera pas sans un pilote logiciel qui gère son matériel. Dans Unix (ou Linux), une partie du matériel est classée comme un périphérique. Les périphériques sont gérés à l'aide de pilotes de périphérique, et les dispositifs réseau (NIC) sont gérés à l'aide de pilotes de dispositifs réseau (network device drivers) et ont un terme collectif appelé dispositifs réseau (net devices). Dans Unix et Linux, vous accédez aux périphériques réseau par des noms tels que eth0.

Dans ns-3, l'abstraction du périphérique réseau englobe à la fois le pilote logiciel et le matériel simulé. Lors de la simulation, le périphérique réseau est « installé » dans un nœud pour lui permettre de communiquer avec d'autres nœuds via des canaux. Comme sur un ordinateur réel, un nœud peut être connecté à plusieurs canaux via plusieurs périphériques. NetDevices.

L'abstraction réseau du périphérique est représentée dans la classe C++ NetDevice. La classe NetDevice fournit des méthodes pour gérer les connexions avec les objets Node et Channel ; et peut être spécialisée par les développeurs en termes de programmation orientée objet. Dans ce guide, nous utiliserons plusieurs versions spécialisées de NetDevice appelées CsmaNetDevice, PointToPointNetDevice et WifiNetDevice. Tout comme l'adaptateur réseau Ethernet est conçu pour fonctionner avec le Ethernet, CsmaNetDevice est conçu pour fonctionner avec le CsmaChannel, PointToPointNetDevice est conçu pour fonctionner avec le PointToPointChannel, et WifiNetDevice — est conçu pour fonctionner avec le WifiChannel.

4.1.5 Assistants topologiques

Dans un réseau réel, vous trouverez des ordinateurs hôtes avec des cartes réseau ajoutées (ou intégrées). Dans ns-3, nous dirions que vous verrez des nœuds avec des NetDevices connectés. Dans un grand réseau simulé, vous devrez organiser des connexions entre plusieurs objets. Nœud, NetDevice et Channel.

Étant donné que la connexion des NetDevices aux nœuds, des NetDevices aux canaux, l'attribution d'adresses IP, etc. dans ns-3 sont des tâches courantes, afin de rendre cela aussi simple que possible, nous fournissons ce qu'on appelle des helpers topologiques. Par exemple, pour créer un NetDevice, vous devez effectuer de nombreuses opérations dans le cœur de ns-3, ajouter une adresse MAC, installer ce périphérique réseau dans un Node, configurer la pile de protocoles du nœud, puis connecter le NetDevice au Channel. Encore plus d'opérations seront nécessaires pour connecter plusieurs périphériques à des canaux multipoints, puis relier des réseaux distincts à un réseau unifié (Internetworks). Nous fournissons des objets d'assistance topologique qui, pour votre commodité, regroupent ces nombreuses opérations dans un modèle facile à utiliser.

4.2 Premier script ns-3

Si vous avez installé le système comme suggéré ci-dessus, vous aurez un release ns-3 dans un répertoire nommé repos dans votre répertoire personnel. Accédez au répertoire release

Si vous n'avez pas ce répertoire, cela signifie que vous n'avez pas spécifié le répertoire de sortie lors de la compilation de la version de ns‑3, exécutez la compilation comme suit :
$ ./waf configure --build-profile=release --out=build/release,
$ ./waf build

là, vous devriez voir une structure de répertoire ressemblant à ceci :

AUTHORS       examples      scratch       utils       waf.bat*
bindings      LICENSE       src           utils.py    waf-tools
build         ns3           test.py*      utils.pyc   wscript
CHANGES.html  README        testpy-output VERSION     wutils.py
doc           RELEASE_NOTES testpy.supp   waf*        wutils.pyc

Allez dans le répertoire examples/tutorial. Vous devriez voir un fichier nommé first.cc. C'est un script qui créera une connexion point à point simple entre deux nœuds et transmettra un paquet entre eux. Regardons ce script ligne par ligne, alors ouvrons first.cc dans votre éditeur préféré.

4.2.1 Code boilerplate
La première ligne du fichier est la ligne de mode de l'éditeur emacs. Elle indique à emacs les conventions de formatage (style de codage) que nous utiliserons dans notre code source.

/* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */

C'est toujours une question assez polémique, donc nous devons clarifier pour l’évacuer immédiatement. Le projet ns‑3, comme la plupart des grands projets, a adopté un style de codage auquel tout le code fourni doit se conformer. Si vous souhaitez contribuer votre code au projet, vous devrez finalement vous conformer au standard de codage de ns‑3, tel que décrit dans le fichier doc/codingstd.txt ou présenté sur la page web du projet : https://www.nsnam.org/develop/contributing-code/coding-style/.

Nous vous recommandons de vous habituer à l’apparence du code ns‑3 et d'appliquer ce standard chaque fois que vous travaillez avec notre code. Toute l'équipe de développement et les contributeurs sont d'accord avec cela après un peu de grognement. La ligne de mode emacs ci-dessus facilite le bon formatage si vous utilisez l'éditeur emacs.

Le simulateur ns‑3 est sous licence avec la GNU General Public License. Vous verrez l'en-tête légal correspondant de la GNU dans chaque fichier de distribution de ns‑3. Vous pouvez souvent voir un avis de droit d'auteur pour l'une des institutions participant au projet ns‑3 au-dessus du texte de la GPL et de l'auteur, affiché ci-dessous.

/* 
* This program is free software; you can redistribute it and/or modify 
* it under the terms of the GNU General Public License version 2 as 
* published by the Free Software Foundation; 
*
* This program is distributed in the hope that it will be useful, 
* but WITHOUT ANY WARRANTY; without even the implied warranty of 
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 
* GNU General Public License for more details. 
* 
* You should have received a copy of the GNU General Public License 
* along with this program; if not, write to the Free Software 
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA 
*/

4.2.2 Modules connectés

Le code proprement dit commence par une série d'instructions d'inclusion (include).

#include "ns3/core-module.h"
#include "ns3/network-module.h"
#include "ns3/internet-module.h"
#include "ns3/point-to-point-module.h"
#include "ns3/applications-module.h"

Pour aider nos utilisateurs de scripts de haut niveau à gérer le grand nombre de fichiers d'en-tête présents dans le système, nous les regroupons selon leur utilisation en grands modules. Nous fournissons un fichier d'en-tête qui chargera récursivement tous les fichiers d'en-tête utilisés dans ce module. Au lieu de chercher quel en-tête vous avez besoin et de peut-être obtenir la bonne liste de dépendances, nous vous offrons la possibilité de charger un groupe de fichiers avec un grand niveau de détails. Ce n'est pas la méthode la plus efficace, mais elle rend certainement l'écriture de scripts beaucoup plus simple.

Chacun des fichiers inclus dans ns‑3 est placé dans un répertoire nommé ns3 (sous-répertoire de construction), afin d'éviter les conflits de noms de fichiers pendant le processus de construction. Le fichier ns3/core-module.h correspond au module ns‑3 que vous trouverez dans le répertoire src/core dans la version que vous avez installée. Dans la liste de ce répertoire, vous trouverez un grand nombre de fichiers d'en-tête. Lorsque vous faites une construction, Waf place les fichiers d'en-tête publics dans le répertoire ns3 dans le sous-répertoire build/debug

Si vous n'avez pas ce répertoire, cela signifie que vous n'avez pas spécifié le répertoire de sortie lors de la compilation de la version de ns‑3, exécutez la compilation comme suit :
$ ./waf configure --build-profile=debug --out=build/debug
$ ./waf build
ou
$ ./waf configure --build-profile=optimized --out=build/optimized
$ ./waf build

ou build/optimized, selon votre configuration. Waf génère également automatiquement un fichier d'inclusion de module pour charger tous les fichiers d'en-tête publics. Puisque vous suivez bien sûr ce guide à la lettre, vous avez déjà effectué

$ ./waf -d debug --enable-examples --enable-tests configure

pour configurer le projet pour effectuer des constructions de débogage, y compris des exemples et des tests. Vous avez également exécuté

$ ./waf

pour construire le projet. Donc maintenant, lorsque vous regardez dans le répertoire ../..../build/debug/ns3, vous trouverez parmi d'autres les fichiers d'en-tête des quatre modules mentionnés ci-dessus. Vous pouvez jeter un coup d'œil au contenu de ces fichiers et constater qu'ils incluent tous les fichiers publics utilisés par les modules correspondants.

4.2.3 Espace de noms ns3

La ligne suivante dans le script first.cc est la déclaration de l'espace de noms.

using namespace ns3;

Le projet ns‑3 est réalisé dans l'espace de noms C++ appelé ns3. Cela regroupe toutes les déclarations liées à ns‑3 en dehors de l'espace de noms global, ce qui, nous l'espérons, facilitera l'intégration avec d'autres codes. L'utilisation de l'opérateur C++ introduit l'espace de noms ns‑3 dans la région déclarative actuelle (globale). C'est une manière élaborée de dire qu'après cette déclaration, vous n'aurez plus besoin d'utiliser l'opérateur de résolution ns3::scope devant tout le code ns‑3 pour l'utiliser. Si vous n'êtes pas familier avec les espaces de noms, consultez pratiquement n'importe quel manuel de C++ et comparez l'espace de noms ns3 avec l'utilisation de l'espace de noms std et des déclarations. using namespace std; dans les exemples travaillant avec l'opérateur de sortie cout et les flux.

4.2.4 Journalisation

La ligne suivante du script est la suivante :

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Nous utiliserons cette déclaration comme un point pratique pour discuter de notre système de documentation. DoxygenSi vous regardez le site web du projet ns‑3, vous trouverez un lien vers « Documentation » dans la barre de navigation. Si vous cliquez sur ce lien, vous serez dirigé vers notre page de documentation. Il y a un lien vers le « Dernier release », qui vous mènera à la documentation de la dernière version stable de ns‑3. Si vous choisissez le lien « API Documentation », vous accéderez à la page de la documentation API de ns‑3.

Sur le côté gauche de la page, vous trouverez une représentation graphique de la structure de la documentation. Un bon point de départ est le « livre » Modules ns‑3 dans l'arborescence de navigation ns‑3. Si vous développez Modules, vous verrez une liste de la documentation des modules ns‑3. Comme discuté ci-dessus, le concept de module ici est directement lié aux fichiers inclus dans le module ci-dessus. Le sous-système de journalisation (logging) de ns‑3 est discuté dans la section Utilisation du module de journalisation, donc nous y reviendrons plus tard dans ce guide, mais vous pouvez en apprendre davantage sur la déclaration ci-dessus en consultant le module Noyau, puis en ouvrant le livre Outils de débogage, puis en sélectionnant la page Journalisation. Cliquez sur Journalisation.

Vous devez maintenant consulter la documentation Doxygen pour le module. Journalisation. Dans la liste des macros en haut de la page, vous verrez une entrée pour NS_LOG_COMPONENT_DEFINE. Avant de cliquer sur le lien, assurez-vous de consulter la « Description détaillée » du module de journalisation afin de comprendre son fonctionnement global. Pour cela, vous pouvez faire défiler vers le bas ou sélectionner « Plus… » sous le diagramme.

Une fois que vous avez une vue d'ensemble de ce qui se passe, allez-y et consultez la documentation sur le NS_LOG_COMPONENT_DEFINE spécifique. Je ne vais pas dupliquer la documentation ici, mais en résumé, cette ligne déclare un composant de journalisation nommé FirstScriptExample, qui permet d'activer et de désactiver l'enregistrement des messages dans la console par un lien sur le nom.

4.2.5 Fonction principale

Dans les lignes suivantes du script, vous verrez

int 
main (int argc, char *argv[])
{ 

C'est simplement la déclaration de la fonction principale de votre programme (script). Comme dans tout programme en C++, vous devez définir la fonction principale, qui s'exécute en premier. Il n'y a rien de spécial ici. Votre script ns-3 est simplement un programme C++. La ligne suivante définit la résolution temporelle à 1 nanoseconde, ce qui est la valeur par défaut :

Time::SetResolution (Time::NS);

La résolution temporelle ou simplement la résolution est la plus petite valeur temporelle pouvant être utilisée (la plus petite différence représentable entre deux valeurs temporelles). Vous ne pouvez changer la résolution qu'une seule fois. Le mécanisme qui permet cette flexibilité consomme de la mémoire, donc une fois que la résolution est explicitement définie, nous libérons la mémoire, empêchant ainsi de futures mises à jour. (Si vous ne définissez pas explicitement la résolution, elle sera par défaut d'une nanoseconde, et la mémoire sera libérée au début de la simulation.)

Les deux lignes suivantes du script sont utilisées pour activer deux composants de journalisation intégrés aux applications EchoClient et EchoServer:

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO); LogComponentEnable("UdpEchoServerApplication", LOG_LEVEL_INFO);

Si vous avez lu la documentation du composant Logging, vous remarquerez qu'il existe plusieurs niveaux de détail d'enregistrement que vous pouvez activer sur chaque composant. Ces deux lignes de code activent la journalisation de débogage au niveau INFO pour les clients et serveurs écho. À ce niveau, l'application imprimera des messages lors de l'envoi et de la réception de paquets pendant la simulation.

Nous allons maintenant passer directement à la création de la topologie et au démarrage de la simulation. Nous utiliserons des objets d'assistance topologique pour faciliter cette tâche.

4.2.6 Utilisation des assistants topologiques

Les deux lignes suivantes de code dans notre script vont en fait créer des objets Node ns-3 qui représenteront des ordinateurs dans la simulation.

NodeContainer nodes;
nodes.Create(2);

Avant de continuer, trouvons la documentation pour la classe NodeContainer. Une autre façon d'accéder à la documentation pour cette classe est à travers l'onglet Classes sur les pages Doxygen. Si vous avez déjà ouvert Doxygen, faites simplement défiler vers le haut de la page et sélectionnez l'onglet Classes. Vous devriez voir un nouvel ensemble d'onglets, dont l'un liste les classes. Sous cet onglet, vous verrez la liste de toutes les classes ns-3. Faites défiler vers le bas jusqu'à ns3::NodeContainer. Lorsque vous trouvez la classe, sélectionnez-la pour accéder à la documentation de cette classe.

Comme nous le savons, l'une de nos abstractions clés est le nœud. Il représente un ordinateur auquel nous allons ajouter des éléments tels que des piles de protocoles, des applications et des cartes périphériques. L'assistant topologique NodeContainer offre un moyen pratique de créer, gérer et accéder à tous les objets Nœud, que nous créons pour lancer la simulation. La première ligne ci-dessus déclare simplement NodeContainer, que nous appelons nodes. La deuxième ligne appelle la méthode Create pour l'objet nodes et demande au conteneur de créer deux nœuds. Comme décrit dans Doxygen, le conteneur demande à la système ns-3 de créer deux objets Nœud et conserve les pointeurs vers ces objets à l'intérieur.

Les nœuds créés dans le script ne font rien pour le moment. La prochaine étape dans la construction de la topologie est de connecter nos nœuds au réseau. La forme de réseau la plus simple que nous soutenons est une connexion point à point entre deux nœuds. Nous allons maintenant établir cette connexion.

PointToPointHelper

Nous établissons une connexion bidirectionnelle en suivant un modèle familier, utilisant un objet auxiliaire topologique pour effectuer le travail de bas niveau nécessaire à la connexion. Rappelons que nos deux principales abstractions NetDevice et Channel. Dans le monde réel, ces termes correspondent grosso modo à des cartes de périphériques et à des câbles réseau. En général, ces deux éléments sont étroitement liés, et personne ne peut compter sur l'échange, par exemple, d'appareils Ethernet via un canal sans fil. Nos aides topologiques suivent cette connexion étroite, et donc, dans ce scénario, vous utiliserez un seul objet PointToPointHelper pour configurer et connecter des objets ns-3 PointToPointNetDevice et PointToPointChannel. Les trois lignes suivantes dans le script :

PointToPointHelper pointToPoint;
pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps")); 
pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms"));

La première ligne,

PointToPointHelper pointToPoint;

crée une instance de l'objet dans la pile PointToPointHelper. Du point de vue de haut niveau, la ligne suivante,

pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps"));

indique à l'objet PointToPointHelper d'utiliser la valeur « 5 Mbps » (cinq mégabits par seconde) comme «DataRate».

D'un point de vue plus spécifique, la ligne « DataRate » correspond à ce que nous appelons un attribut PointToPointNetDevice. Si vous regardez Doxygen pour la classe ns3::PointToPointNetDevice et dans la documentation de la méthode GetTypeId vous trouverez une liste des attributs définis pour le dispositif. Parmi eux, il y aura l'attribut «DataRate». La plupart des objets visibles par l'utilisateur de ns-3 ont des listes d'attributs similaires. Nous utilisons ce mécanisme pour configurer simplement la simulation sans recompilation, comme vous le verrez dans la section suivante.

De même que «DataRate» dans PointToPointNetDevice, vous trouverez l'attribut « Delay », associé à PointToPointChannel. La ligne finale,

pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms"));

dit PointToPointHelper utilise la valeur « 2 ms » (deux millisecondes) comme valeur de délai de propagation sur le canal point à point qu'il crée ensuite.

NetDeviceContainer

À ce stade, notre script contient NodeContainer, qui contient deux nœuds. Nous avons PointToPointHelper, qui est préparé pour créer des objets PointToPointNetDevices et les connecter à l'aide d'un objet PointToPointChannel. Tout comme nous avons utilisé un objet auxiliaire de topologie NodeContainer pour créer des nœuds, nous demanderons à PointToPointHelper de s'occuper pour nous de la création, de la configuration et de la mise en place de nos dispositifs. Nous aurons besoin d'une liste de tous les objets créés NetDevice, c'est pourquoi nous utilisons NetDeviceContainer pour leur stockage de la même manière que nous avons utilisé NodeContainer pour le stockage des nœuds que nous avons créés. Les deux lignes de code suivantes,

NetDeviceContainer devices;
devices = pointToPoint.Install (nodes);

terminent la configuration des appareils et du canal. La première ligne déclare le conteneur d'appareils mentionné ci-dessus, et la seconde exécute le travail principal. La méthode Installer de l'installation PointToPointHelper prend NodeContainer comme paramètre. À l'intérieur NetDeviceContainer pour chaque nœud présent dans NodeContainer est créé (pour la communication point à point, il doit y en avoir exactement deux) PointToPointNetDevice est créé et stocké dans le conteneur d'appareils. PointToPointChannel est créé, et deux y sont joints PointToPointNetDevices. Une fois les objets créés, les attributs stockés dans PointToPointHelper, sont utilisés pour initialiser les attributs correspondants dans les objets créés.

Après l'appel de pointToPoint.Install (nodes) , nous aurons deux nœuds, chacun avec un dispositif réseau "point à point" installé et un canal "point à point" entre eux. Les deux appareils seront configurés pour transmettre des données à une vitesse de cinq mégabits par seconde avec un délai de transmission sur le canal de deux millisecondes.

InternetStackHelper

Nous avons maintenant configuré les nœuds et les dispositifs, mais nos nœuds n'ont pas de piles de protocoles installées. Les deux lignes de code suivantes s'occuperont de cela.

InternetStackHelper stack;
stack.Install (nodes);

InternetStackHelper représente un assistant topologique pour les piles Internet, semblable à PointToPointHelper pour les dispositifs réseau à deux points. La méthode Installer prend NodeContainer comme paramètre. Lors de l'exécution, elle installera la pile Internet (TCP, UDP, IP, etc.) sur chaque nœud du conteneur.

Ipv4AddressHelper

Ensuite, nous devons associer nos dispositifs aux adresses IP. Nous fournissons un assistant topologique pour gérer la distribution des adresses IP. La seule API visible pour l'utilisateur est la configuration de l'adresse IP de base et du masque de réseau à utiliser lors de la distribution effective des adresses (cela se fait à un niveau inférieur au sein de l'assistant). Les deux lignes de code suivantes dans notre exemple de script first.cc,

Ipv4AddressHelper address;
address.SetBase ("10.1.1.0", "255.255.255.0");

déclare un objet auxiliaire d'adresse et lui indique qu'il doit commencer à attribuer des adresses IP à partir du réseau 10.1.1.0, en utilisant le masque de sous-réseau 255.255.255.0 pour la détermination. Par défaut, les adresses attribuées commenceront par un et augmenteront de manière monotone, ainsi la première adresse attribuée de cette plage sera 10.1.1.1, puis 10.1.1.2, etc. En réalité, au niveau le plus bas, le système ns-3 mémorise toutes les adresses IP attribuées et génère une erreur fatale si vous avez accidentellement créé une situation où la même adresse est générée deux fois (d'ailleurs, cette erreur est difficile à déboguer).

La ligne de code suivante,

Ipv4InterfaceContainer interfaces = address.Assign (devices);

effectue l'attribution effective de l'adresse. Dans ns-3, nous établissons une liaison entre l'adresse IP et le dispositif en utilisant l'objet Ipv4Interface. Tout comme nous avons parfois besoin d'une liste des dispositifs réseau créés par l'assistant pour une utilisation ultérieure, nous avons parfois besoin d'une liste d'objets Ipv4Interface. Ipv4InterfaceContainer fournit cette fonctionnalité.

Nous avons construit un réseau point à point, avec des piles installées et des adresses IP attribuées. Maintenant, nous avons besoin d'applications sur chaque nœud pour générer du trafic.

4.2.7 Utilisation de l'Application

Une autre des abstractions clés du système ns-3 est Application (application). Dans ce scénario, nous utilisons deux spécialisations de la classe de base Application ns-3 appelée UdpEchoServerApplication et UdpEchoClientApplication. Comme dans les cas précédents, nous utilisons des objets auxiliaires pour configurer et gérer les objets de base. Ici, nous utilisons UdpEchoServerHelper et UdpEchoClientHelperdes objets pour nous simplifier la vie.

UdpEchoServerHelper

Les lignes de code suivantes dans notre exemple de script first.cc sont utilisées pour configurer l'application de serveur UDP écho sur l'un des nœuds que nous avons créés précédemment.

UdpEchoServerHelper echoServer (9);

ApplicationContainer serverApps = echoServer.Install (nodes.Get (1));
serverApps.Start (Seconds (1.0));
serverApps.Stop (Seconds (10.0));

La première ligne de code dans le fragment ci-dessus crée UdpEchoServerHelper. Comme d'habitude, ce n'est pas une application en soi, c'est un objet qui nous aide à créer de véritables applications. Un de nos accords consiste à transmettre les attributs nécessaires au constructeur de l'objet auxiliaire (assistant). Dans ce cas, l'assistant ne peut rien faire d'utile s'il n'a pas reçu le numéro de port sur lequel le serveur attendra les paquets, ce numéro doit également être connu du client. Dans ce cas, nous passons le numéro de port au constructeur de l'assistant. Le constructeur, pour sa part, exécute simplement SetAttribute avec la valeur fournie. Plus tard, si vous le souhaitez, vous pourrez définir une autre valeur pour l'attribut « Port » à l'aide de SetAttribute.

Comme beaucoup d'autres objets auxiliaires, l'objet UdpEchoServerHelper a une méthode Installer. L'exécution de cette méthode conduit en fait à la création d'une application de serveur écho de base, qui est liée à un nœud. Il est intéressant de noter que la méthode Installer prend NodeContainer aussi comme paramètre, tout comme les autres Installer méthodes que nous avons vues.

La conversion implicite en C++ qui fonctionne ici prend le résultat de la méthode node.Get(1) (qui retourne un pointeur intelligent vers l'objet nœud — Ptr) et l'utilise dans le constructeur pour un objet anonyme NodeContainer, qui est ensuite passé à la méthode Installer. Si vous ne pouvez pas déterminer dans le code C++ quelle méthode avec quelle signature se compile et s'exécute, alors cherchez parmi les conversions implicites.

Maintenant, nous voyons que echoServer.Install s'apprête à installer l'application UdpEchoServerApplication sur le nœud trouvé dans NodeContainer, que nous utilisons pour gérer nos nœuds, le nœud avec l'index 1. La méthode Installer retournera le conteneur qui contient des pointeurs vers toutes les applications (dans ce cas une seule, car nous avons passé un anonyme NodeContainer, contenant un nœud) créé par l'assistant.

Les applications doivent indiquer le moment de début de la génération de trafic « start » et peuvent également avoir besoin d'indiquer le moment où elle doit s'arrêter « stop ». Nous fournissons les deux paramètres. Ces temps sont définis à l'aide des méthodes ApplicationContainer Commencer et Arrêter. Ces méthodes prennent des paramètres de type Temps. Dans ce cas, nous utilisons une séquence explicite de conversions C++ pour prendre un C++ double 1.0 et le convertir en un objet tns-3 Time, utilisant l'objet Seconds pour la conversion en secondes. N'oubliez pas que les règles de conversion peuvent être contrôlées par l'auteur du modèle, et le C++ a ses propres règles, donc vous ne pouvez pas toujours vous attendre à ce que les paramètres soient convertis comme vous l'aviez prévu. Deux lignes,

serverApps.Start (Seconds (1.0));
serverApps.Stop (Seconds (10.0));

mèneront à l'exécution de l'application d'écho serveur (s'active automatiquement) après une seconde du début de la simulation et s'arrête (se désactive) après dix secondes de simulation. Étant donné que nous avons déclaré l'événement de simulation (l'événement d'arrêt de l'application), qui sera exécuté après dix secondes, il y aura au moins dix secondes de fonctionnement du réseau simulé.

UdpEchoClientHelper

L'application cliente echo est configurée de façon pratiquement identique au serveur. Il existe un objet de base UdpEchoClientApplication, géré par
UdpEchoClientHelper.

UdpEchoClientHelper echoClient (interfaces.GetAddress (1), 9);
echoClient.SetAttribute ("MaxPackets", UintegerValue (1));
echoClient.SetAttribute ("Interval", TimeValue (Seconds (1.0)));
echoClient.SetAttribute ("PacketSize", UintegerValue (1024));

ApplicationContainer clientApps = echoClient.Install (nodes.Get (0));
clientApps.Start (Seconds (2.0));
clientApps.Stop (Seconds (10.0));

Cependant, pour le client d'écho, nous devons définir cinq attributs différents. Les deux premiers attributs sont définis lors de la création UdpEchoClientHelper. Nous passons les paramètres qui sont utilisés (à l'intérieur de l'assistant) pour définir les attributs "RemoteAddress" et "RemotePort" conformément à notre accord sur la transmission des paramètres nécessaires au constructeur de l'assistant.

Rappelons que nous avons utilisé Ipv4InterfaceContainer pour suivre les adresses IP que nous avons attribuées à nos appareils. L'interface zéro dans le conteneur d'interfaces correspondra à l'adresse IP du nœud zéro dans le conteneur des nœuds. La première interface dans le conteneur d'interfaces correspond à l'adresse IP du premier nœud dans le conteneur des nœuds. Donc, dans la première ligne de code (en haut), nous créons l'assistant et lui disons que l'adresse distante du client sera l'adresse IP attribuée au nœud où se trouve le serveur. Nous indiquons également qu'il faut organiser l'envoi des paquets au neuvième port.

L'attribut «MaxPackets» informe le client du nombre maximum de paquets que nous pouvons envoyer pendant la simulation. L'attribut «Interval» indique au client combien de temps attendre entre les paquets, et l'attribut «PacketSize» indique au client la taille que doit avoir la charge utile du paquet. Grâce à cette combinaison d'attributs, nous disons au client d'envoyer un paquet de 1024 octets.

Comme dans le cas du serveur d'écho, nous définissons les attributs pour le client d'écho Commencer et Arrêter, mais ici nous lançons le client une seconde après avoir allumé le serveur (deux secondes après le début de la simulation).

4.2.8 Simulateur

À ce stade, nous devons lancer la simulation. Cela se fait à l'aide de la fonction globale Simulator::Run.

Simulator::Run ();

Lorsque nous avons précédemment appelé les méthodes,

serverApps.Start (Seconds (1.0));
serverApps.Stop (Seconds (10.0));
... 
clientApps.Start (Seconds (2.0));
clientApps.Stop (Seconds (10.0));

nous avons effectivement planifié des événements dans le simulateur pour 1,0 seconde, 2,0 secondes et deux événements à 10,0 secondes. Après avoir appelé Simulator::Run, le système commencera à parcourir la liste des événements planifiés et à les exécuter. Il commencera d'abord par l'événement prévu pour 1,0 seconde, ce qui activera l'application du serveur d'écho (cet événement peut, à son tour, planifier de nombreux autres événements). Ensuite, il lancera l'événement prévu pour t = 2,0 secondes, qui démarrera l'application du client d'écho. Encore une fois, cet événement peut planifier encore beaucoup d'autres événements. L'implémentation de l'événement de lancement dans le client d'écho commencera la phase de transfert de données de la simulation en envoyant un paquet au serveur.

L'acte d'envoyer un paquet au serveur déclenchera une chaîne d'événements qui seront automatiquement planifiés en coulisses et qui mettront en œuvre la mécanique de l'envoi de paquets d'échos en fonction des paramètres de synchronisation que nous avons établis dans le scénario.

En fin de compte, comme nous n'envoyons qu'un seul paquet (rappelons que l'attribut MaxPackets était fixé à un), la chaîne d'événements initiée par cette unique requête d'écho client se terminera, et la simulation passera en mode attente. Une fois cela fait, les événements restants à traiter seront des événements Arrêter pour le serveur et le client. Lorsque ces événements seront exécutés, il n'y aura plus d'événements à traiter et Simulator::Run retournera le contrôle. La simulation est terminée.

Il ne reste plus qu'à nettoyer. Cela se fait en appelant la fonction globale Simulator::Destroy. Étant donné que des fonctions d'assistants (ou du code de bas niveau ns-3) ont été invoquées, qui sont organisées pour insérer des crochets dans le simulateur afin de détruire tous les objets qui ont été créés. Vous n'avez pas besoin de suivre ces objets vous-même — tout ce que vous devez faire, c'est appeler Simulator::Destroy et sortir. Le système ns-3 fera ce travail difficile pour vous. Les lignes restantes de notre premier script ns-3, first.cc, font exactement cela :

Simulator::Destroy ();
return 0;
}

Quand le simulateur s'arrêtera-t-il ?

ns-3 est un simulateur d'événements discrets (DE). Dans un tel simulateur, chaque événement est lié au temps de son exécution, et la simulation se poursuit en traitant les événements dans l'ordre de leur apparition au cours de la simulation. Les événements peuvent entraîner la planification d'événements futurs (par exemple, un minuteur peut se reprogrammer pour terminer un compte à rebours dans l'intervalle suivant).

Les événements initiaux sont généralement initiés par un objet, par exemple, IPv6 planifiera des services dans le réseau, des requêtes de voisins, etc. L'application planifie le premier événement d'envoi de paquet, etc. Lorsqu'un événement est traité, il peut générer zéro, un ou plusieurs événements. À mesure que la simulation progresse, les événements se terminent simplement ou en génèrent de nouveaux. La simulation s'arrêtera automatiquement si la file d'attente des événements est vide ou si un événement spécial est détecté Arrêter. L'événement Arrêter est généré par la fonction Simulator::Stop (arrêter le temps).

Il existe un cas typique où Simulator::Stop est absolument nécessaire pour arrêter la simulation : lorsque des événements auto-sustainants sont présents. Les événements auto-sustainants (ou répétitifs) sont des événements qui se reprogramment toujours. Par conséquent, ils gardent toujours la file d'attente des événements non vide. Il existe de nombreux protocoles et modules contenant des événements répétitifs, par exemple :

• FlowMonitor — vérification périodique des paquets perdus ;

• RIPng — diffusion périodique de mises à jour de tables de routage ;

• etc.

Dans de tels cas, Simulator::Stop est nécessaire pour arrêter la simulation correctement. De plus, lorsque ns-3 est en mode émulation, RealTimeSimulator est utilisé pour synchroniser les horloges de simulation avec les horloges de la machine, et Simulator::Stop est nécessaire pour arrêter le processus.

De nombreux programmes de simulation dans le manuel ne sont pas appelés Simulator::Stop de manière explicite, car elles se terminent automatiquement lors de l'épuisement des événements dans la file d'attente. Cependant, ces programmes accepteront également l'appel à Simulator::Stop. Par exemple, l'instruction supplémentaire suivante dans le premier exemple de programme planifiera un arrêt explicite à la 11ème seconde :

+ Simulator::Stop (Seconds (11.0));
  Simulator::Run ();
  Simulator::Destroy ();
  return 0;
}

Ce qui précède ne modifiera en fait pas le comportement de ce programme, car cette simulation spécifique se termine naturellement après 10 secondes. Mais si vous deviez modifier le temps d'arrêt dans l'instruction ci-dessus de 11 secondes à 1 seconde, vous remarqueriez que la simulation s'arrête avant que n'importe quelle sortie n'apparaisse à l'écran (la sortie se produisant environ 2 secondes après le temps de simulation).

Il est important d'appeler Simulator::Stop avant d'appeler Simulator::Run ; sinon, Simulator::Run peut ne jamais rendre le contrôle au programme principal pour effectuer l'arrêt !

4.2.9 Assemblage de votre scénario

Nous avons rendu la création de vos scripts simples triviale. Tout ce que vous avez à faire est de placer votre script dans le répertoire scratch, et il sera automatiquement compilé lorsque vous exécuterez Waf. Essayons. Revenez au répertoire supérieur et copiez examples/tutorial/first.cc dans le répertoire scratch

$ cd ../..
$ cp examples/tutorial/first.cc scratch/myfirst.cc

Maintenant, compilez votre premier exemple de script en utilisant waf:

$ ./waf

Vous devez voir des messages indiquant que votre premier exemple a été créé avec succès.

Waf : Entrée dans le répertoire `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
[614/708] cxx: scratch/myfirst.cc -> build/debug/scratch/myfirst_3.o
[706/708] cxx_link: build/debug/scratch/myfirst_3.o -> build/debug/scratch/myfirst
Waf : Sortie du répertoire `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' terminé avec succès (2.357s)

Vous pouvez maintenant exécuter l'exemple (notez que si vous compilez votre programme dans le répertoire scratch, vous devez également l'exécuter à partir de scratch):

$ ./waf --run scratch/myfirst

Vous devriez voir une sortie similaire :

Waf : Entrée dans le répertoire `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf : Sortie du répertoire `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' terminé avec succès (0.418s) Envoyé 1024 octets à 10.1.1.2
Reçu 1024 octets de 10.1.1.1
Reçu 1024 octets de 10.1.1.2

Ici, vous voyez que le système de construction vérifie que le fichier a été assemblé, puis le lance. Vous constatez que l'enregistrement du client d'écho indique qu'il a envoyé un paquet de 1024 octets au serveur d'écho 10.1.1.2. Vous voyez également l'enregistrement du serveur d'écho qui indique qu'il a reçu 1024 octets de 10.1.1.1. Le serveur d'écho renvoie silencieusement le paquet, et vous voyez dans le journal du client d'écho qu'il a reçu son paquet de retour du serveur.

4.3 Code source de ns-3

Maintenant que vous avez utilisé certains des assistants ns-3, vous pouvez jeter un œil à quelques codes sources qui implémentent cette fonctionnalité. Le code le plus récent peut être consulté sur notre serveur web à l'adresse suivante : https://gitlab.com/nsnam/ns-3-dev.git. Là, vous verrez une page de synthèse Mercurial pour notre arbre de développement ns-3. En haut de la page, vous verrez plusieurs liens,

summary | shortlog | changelog | graph | tags | files

Allez-y et choisissez le lien vers les fichiers. Voici à quoi ressemblera le niveau supérieur de la plupart de nos dépôts :

drwxr-xr-x                               [up]
drwxr-xr-x                               bindings python  files
drwxr-xr-x                               doc              files
drwxr-xr-x                               examples         files
drwxr-xr-x                               ns3              files
drwxr-xr-x                               scratch          files
drwxr-xr-x                               src              files
drwxr-xr-x                               utils            files
-rw-r--r-- 2009-07-01 12:47 +0200 560    .hgignore        file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 1886   .hgtags          file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 1276   AUTHORS          file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 30961  CHANGES.html     file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 17987  LICENSE          file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 3742   README           file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 16171  RELEASE_NOTES    file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 6      VERSION          file | revisions | annotate
-rwxr-xr-x 2009-07-01 12:47 +0200 88110  waf              file | revisions | annotate
-rwxr-xr-x 2009-07-01 12:47 +0200 28     waf.bat          file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 35395  wscript          file | revisions | annotate
-rw-r--r-- 2009-07-01 12:47 +0200 7673   wutils.py        file | revisions | annotate

Nos exemples de scripts se trouvent dans le répertoire examples. Si vous cliquez sur les exemples, vous verrez une liste de sous-répertoires. L'un des fichiers dans le sous-répertoire tutorial — first.cc. Si vous cliquez sur first.cc , vous verrez le code que vous venez d'étudier.

Le code source se trouve principalement dans le répertoire src. Vous pouvez voir le code source en cliquant sur le nom du répertoire ou en cliquant sur le lien des fichiers à droite du nom du répertoire. Si vous cliquez sur le répertoire src, vous obtiendrez une liste des sous-répertoires src. Si vous cliquez ensuite sur le sous-répertoire core, vous trouverez une liste de fichiers. Le premier fichier que vous verrez (au moment de la rédaction de ce guide) est abort.h. Si vous cliquez sur le lien abort.h, vous serez redirigé vers le fichier source pour abort.h, qui contient des macros utiles pour quitter les scripts en cas de conditions anormales. Le code source pour les helpers que nous avons utilisés dans ce chapitre peut être trouvé dans le répertoire src/Applications/helper. N'hésitez pas à explorer l'arborescence des répertoires pour comprendre ce qui se trouve où et vous familiariser avec le style de programmation de ns‑3.

Source : habr.com