ProHoster > Blog > administration > Tutoriel du simulateur de réseau ns-3. chapitre 5

Tutoriel du simulateur de réseau ns-3. chapitre 5

Tutoriel du simulateur de réseau ns-3. chapitre 5
chapitre 1,2
chapitre 3
chapitre 4

5 paramètres
5.1 Utilisation du module de journalisation
5.1.1 Aperçu de la journalisation
5.1.2 Activer la journalisation
5.1.3 Ajout de la journalisation à votre code
5.2 Utilisation des arguments de ligne de commande
5.2.1 Remplacement des valeurs d'attribut par défaut
5.2.2 Capturer vos propres commandes
5.3 Utilisation du système de traçage
5.3.1 Traçage ASCII
Analyse des traces ASCII
5.3.2 Suivi du PPCE

Chapitre 5

réglage

5.1 Utilisation du module de journalisation

Nous avons déjà brièvement examiné le module de journalisation ns-3 en consultant le script premier.cc. Dans ce chapitre, nous examinerons de plus près les utilisations possibles du sous-système de journalisation.

5.1.1 Aperçu de la journalisation

De nombreux grands systèmes prennent en charge une sorte de fonction de journalisation des messages, et ns-3 ne fait pas exception. Dans certains cas, seuls les messages d'erreur sont écrits dans la « console opérateur » (qui est généralement stderr sur les systèmes basés sur Unix). Sur d'autres systèmes, des messages d'avertissement peuvent être affichés ainsi que des informations plus détaillées. Dans certains cas, les outils de journalisation sont utilisés pour générer des messages de débogage qui peuvent rapidement brouiller la sortie.

Le subHRD utilisé dans ns-3 suppose que tous ces niveaux de contenu informationnel sont utiles, et nous proposons une approche sélective et en couches de la journalisation des messages. La journalisation peut être complètement désactivée, activée par composant ou globalement. À cette fin, des niveaux réglables de contenu d’information sont utilisés. Le module de journalisation ns-3 fournit un moyen relativement simple d'obtenir des informations utiles à partir de votre simulation.

Vous devez comprendre que nous fournissons un mécanisme à usage général - le traçage - pour extraire les données de vos modèles, qui devrait être la sortie préférée pour les simulations (pour plus d'informations sur notre système de traçage, voir la section 5.3 du didacticiel). La journalisation doit être la méthode privilégiée pour obtenir des informations de débogage, des avertissements, des messages d'erreur ou pour générer rapidement des messages à partir de vos scripts ou modèles à tout moment.

Actuellement, le système définit sept niveaux (types) de messages de journal par ordre croissant de contenu informatif.

  • LOG_ERROR - journalisation des messages d'erreur (macro associée : NS_LOG_ERROR) ;
  • LOG_WARN - Consigner les messages d'avertissement (macro associée : NS_LOG_WARN) ;
  • LOG_DEBUG - Enregistre les messages de débogage spéciaux relativement rares (macro associée : NS_LOG_DEBUG) ;
  • LOG_INFO - enregistrement des messages d'information sur l'avancement du programme (macro associée : NS_LOG_INFO) ;
  • LOG_FUNCTION - Enregistre les messages décrivant chaque fonction appelée (deux macros associées : NS_LOG_FUNCTION, utilisée pour les fonctions membres, et NS_LOG_FUNCTION_NOARGS, utilisée pour les fonctions statiques) ;
  • LOG_LOGIC - messages de journalisation décrivant le flux logique au sein d'une fonction (macro associée : NS_LOG_LOGIC) ;
  • LOG_ALL - Enregistre tout ce qui est mentionné ci-dessus (aucune macro associée).
    Pour chaque type (LOG_TYPE), il existe également un LOG_LEVEL_TYPE qui, s'il est utilisé, permet de journaliser tous les niveaux supérieurs en plus de son propre niveau. (En conséquence, LOG_ERROR et LOG_LEVEL_ERROR, et LOG_ALL et LOG_LEVEL_ALL sont fonctionnellement équivalents.) Par exemple, l'activation de LOG_INFO autorisera uniquement les messages fournis par la macro NS_LOG_INFO, tandis que l'activation de LOG_LEVEL_INFO inclura également les messages fournis par les macros NS_LOG_DEBUG, NS_LOG_WARN et NS_LOG_ERROR.

Nous fournissons également une macro de journalisation inconditionnelle qui est toujours affichée, quel que soit le niveau de journalisation ou le composant de sélection.

  • NS_LOG_UNCOND - Journalisation inconditionnelle du message associé (pas de niveau de journalisation associé).

Chaque niveau peut être interrogé individuellement ou cumulativement. La journalisation peut être configurée à l'aide de la variable d'environnement sh NS_LOG ou en enregistrant un appel de fonction système. Comme indiqué précédemment, le système de journalisation dispose d'une documentation Doxygen et c'est le bon moment pour la consulter si vous ne l'avez pas déjà fait.

Maintenant que vous avez lu la documentation en détail, utilisons ces connaissances pour obtenir des informations intéressantes à partir de l'exemple de script. scratch/monpremier.ccque vous avez déjà compilé.

5.1.2 Activer la journalisation

Utilisons la variable d'environnement NS_LOG pour exécuter quelques journaux supplémentaires, mais d'abord, juste pour vous repérer, exécutez le dernier script comme vous l'avez fait précédemment,

$ ./waf --run scratch/myfirst

Vous devriez voir la sortie familière du premier exemple de programme ns-3

$ Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' 'build'
finished successfully (0.413s)
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.1.2

Il s'avère que les messages « envoyés » et « reçus » que vous voyez ci-dessus sont en réalité des messages enregistrés provenant de UdpEchoClientApplicationUdpEchoClientApplication и UdpEchoServerApplicationUdpEchoServerApplication. Par exemple, nous pouvons demander à l'application client d'imprimer des informations supplémentaires en définissant son niveau de journalisation via la variable d'environnement NS_LOG.

À partir de maintenant, je vais supposer que vous utilisez un shell de type sh qui utilise la syntaxe "VARIABLE=value". Si vous utilisez un shell de type csh, vous devrez alors convertir mes exemples en la syntaxe "setenv variable value" requise par ces shells.

Actuellement, l'application client d'écho UDP répond à la ligne de code suivante dans scratch/monpremier.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

Il active le niveau de journalisation LOG_LEVEL_INFO. Lorsque nous passons un indicateur de niveau de journalisation, nous activons en fait ce niveau ainsi que tous les niveaux inférieurs. Dans ce cas, nous avons activé NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN et NS_LOG_ERROR. Nous pouvons augmenter le niveau de journalisation et obtenir plus d'informations, sans modifications de script ni recompilation, en définissant la variable d'environnement NS_LOG comme suit :

$ export NS_LOG=UdpEchoClientApplication=level_all

Nous définissons donc la variable sh shell NS_LOG à la valeur suivante,

UdpEchoClientApplication=level_all

Le côté gauche de l'affectation est le nom du composant journalisé que nous voulons configurer, et le côté droit est l'indicateur que nous voulons lui appliquer. Dans ce cas, nous allons activer tous les niveaux de débogage dans l'application. Si vous exécutez le script avec NS_LOG défini de cette façon, le système de journalisation ns-3 acceptera les modifications et vous devriez voir le résultat suivant :

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.404s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
Received 1024 bytes from 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()

Les informations de débogage supplémentaires fournies par l'application se trouvent désormais au niveau NS_LOG_FUNCTION. Il montre chaque instance d'un appel de fonction pendant l'exécution du script. En règle générale, dans les fonctions de méthode il est préférable d'utiliser (au minimum)NS_LOG_FUNCTION (this)... Utilisation NS_LOG_FUNCTION_NOARGS ()
uniquement dans les fonctions statiques. Cependant, notez que le système ns-3 n'est pas tenu de prendre en charge une fonctionnalité de journalisation. La décision concernant la quantité d’informations à enregistrer est laissée au développeur du modèle individuel. Dans le cas des applications d'écho, une grande quantité de résultats de journalisation est disponible.

Vous pouvez maintenant afficher un journal des appels de fonction effectués par l'application. Si vous regardez attentivement, vous remarquerez deux points entre la ligne UdpEchoClientApplicationUdpEchoClientApplication et le nom de la méthode, où vous pouvez vous attendre à voir l'opérateur de portée C++ (: :). C'est intentionnel.

Il ne s'agit pas réellement du nom de la classe, mais du nom du composant de journalisation. Lorsqu'il y a une correspondance entre un fichier source et une classe, il s'agit généralement du nom de la classe, mais vous devez réaliser qu'il ne s'agit pas réellement du nom de la classe et qu'il y a un simple deux-points au lieu de deux deux-points. C'est une façon de vous aider à séparer conceptuellement le nom du bean de journalisation du nom de la classe d'une manière relativement subtile.

Cependant, dans certains cas, il peut être difficile de déterminer quelle méthode génère réellement le message de journal. Si vous regardez le texte ci-dessus, vous vous demandez peut-être où se trouve la ligne "Received 1024 bytes from 10.1.1.2" Vous pouvez résoudre ce problème en réglant le niveau préfixe_fonc à la variable d'environnement NS_LOG. Essayez ce qui suit :

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

Notez que les guillemets sont nécessaires car la barre verticale que nous utilisons pour représenter l'opération OU est également un connecteur de canal Unix. Maintenant, si vous exécutez le script, vous verrez que le système de journalisation garantit que chaque message d'un journal donné est préfixé par le nom du composant.

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.417s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()

Vous pouvez maintenant voir que tous les messages provenant de l'application client d'écho UDP sont identifiés comme tels. Message "Received 1024 bytes from 10.1.1.2" est désormais clairement identifié comme provenant de l'application client echo. Le message restant doit provenir de l'application serveur d'écho UDP. Nous pouvons activer ce composant en entrant une liste de composants séparés par deux points dans la variable d'environnement NS_LOG.

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func:
               UdpEchoServerApplication=level_all|prefix_func'

Attention : Dans l'exemple de texte ci-dessus, vous devrez supprimer le caractère de nouvelle ligne après les deux points (:), il est utilisé pour formater le document. Maintenant, si vous exécutez le script, vous verrez tous les messages de journal des applications d'écho client et serveur. Vous pouvez voir que cela peut être très utile lors du débogage.

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.406s)
UdpEchoServerApplication:UdpEchoServer()
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoServerApplication:StartApplication()
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
UdpEchoServerApplication:HandleRead(): Echoing packet
UdpEchoClientApplication:HandleRead(0x624920, 0x625160)
UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
UdpEchoServerApplication:StopApplication()
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Il est aussi parfois utile de pouvoir voir l'heure de simulation à laquelle le message de journal a été généré. Vous pouvez le faire en ajoutant le bit OR préfixe_heure:

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func|prefix_time: UdpEchoServerApplication=level_all|prefix_func|prefix_time'

Encore une fois, vous devrez supprimer le caractère de nouvelle ligne ci-dessus. Si vous exécutez maintenant le script, vous devriez voir le résultat suivant :

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.418s)
0s UdpEchoServerApplication:UdpEchoServer()
0s UdpEchoClientApplication:UdpEchoClient()
0s UdpEchoClientApplication:SetDataSize(1024)
1s UdpEchoServerApplication:StartApplication()
2s UdpEchoClientApplication:StartApplication()
2s UdpEchoClientApplication:ScheduleTransmit()
2s UdpEchoClientApplication:Send()
2s UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
2.00369s UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
2.00369s UdpEchoServerApplication:HandleRead(): Echoing packet
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
10s UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Veuillez noter que le constructeur pour UdpEchoServer a été appelé pendant la simulation 0 seconde. Cela se produit en réalité avant le début de la simulation, mais le temps affiché est de zéro seconde. La même chose est vraie pour le message du constructeur UdpEchoClient.

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.418s)
0s UdpEchoServerApplication:UdpEchoServer()
0s UdpEchoClientApplication:UdpEchoClient()
0s UdpEchoClientApplication:SetDataSize(1024)
1s UdpEchoServerApplication:StartApplication()
2s UdpEchoClientApplication:StartApplication()
2s UdpEchoClientApplication:ScheduleTransmit()
2s UdpEchoClientApplication:Send()
2s UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
2.00369s UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
2.00369s UdpEchoServerApplication:HandleRead(): Echoing packet
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
10s UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Rappelons que le script scratch/premier.cc démarré l'application serveur d'écho une seconde avant le début de la simulation. Vous pouvez maintenant voir que la méthode Lancer l'application le serveur est effectivement appelé dans la première seconde. Vous remarquerez peut-être également que le client echo démarre dans la deuxième seconde de la simulation, comme nous l'avons demandé dans le script.

Vous pouvez désormais suivre l'avancement de la simulation sur appel ProgrammerTransmettre dans le client qui appelle le rappel HandleRead Send dans l'application serveur d'écho. Notez que le temps écoulé pour envoyer un paquet sur une liaison point à point est de 3,69 millisecondes. Vous pouvez voir que le serveur d'écho enregistre un message indiquant qu'il a répondu au paquet, puis, après un délai de canal, vous voyez que le client d'écho reçoit le paquet d'écho dans sa méthode HandleRead.

Dans cette simulation, beaucoup de choses se passent sans que vous vous en rendiez compte. Mais vous pouvez suivre l'ensemble du processus très facilement en activant tous les composants de journalisation dans le système. Essayez de définir la variable NS_LOG sur la valeur suivante :

$ export 'NS_LOG=*=level_all|prefix_func|prefix_time'

L'astérisque ci-dessus est un caractère générique pour le composant de journalisation. Cela inclura toutes les entrées de tous les composants utilisés dans la simulation. Je ne reproduirai pas la sortie ici (au moment de la rédaction, elle produit 1265 XNUMX lignes de sortie pour un seul paquet d'écho), mais vous pouvez rediriger ces informations vers un fichier et les afficher dans votre éditeur préféré.

$ ./waf --run scratch/myfirst > log.out 2>&1

Personnellement, j'utilise cette version extrêmement verbeuse de la journalisation lorsque j'ai un problème et que je n'ai aucune idée de l'endroit où les choses se sont mal passées. Je peux suivre l'exécution du code assez facilement sans définir de points d'arrêt ni parcourir le code dans le débogueur. Je peux simplement éditer la sortie dans mon éditeur préféré, rechercher ce à quoi je m'attends et voir se produire quelque chose auquel je ne m'attendais pas. Une fois que j'ai une idée générale de ce qui ne va pas, je saute dans le débogueur pour explorer le problème. Ce type de sortie peut être particulièrement utile lorsque votre script fait quelque chose de complètement inattendu. Si vous utilisez uniquement le débogueur, vous risquez de manquer complètement une touche. L'enregistrement rend ces virages visibles.

5.1.3 Ajout de la journalisation à votre code

Vous pouvez ajouter de nouvelles entrées à vos simulations en appelant le composant de journal à partir de plusieurs macros. Faisons-le dans un script mapremière.cc, que nous avons dans le répertoire « clean ». Rappelons que nous avons défini un composant de journalisation dans ce scénario :

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Vous savez que vous pouvez activer la journalisation de tous les messages de ce composant en définissant la variable d'environnement NS_LOG à différents niveaux. Allons-y et ajoutons quelques entrées au script. La macro utilisée pour ajouter des messages de niveau information au journal est NS_LOG_INFO. Ajoutons un message (juste avant de commencer à créer des nœuds) qui vous indique que le script est en phase "Création de topologie". Cela se fait dans l'extrait de code suivant,
Ouvrir scratch/monpremier.cc dans votre éditeur préféré et ajoutez la ligne,
NS_LOG_INFO ("Creating Topology");
juste avant les lignes,

NodeContainer nodes;
nodes.Create (2);

Compilez maintenant le script en utilisant wafet effacez la variable NS_LOG pour désactiver le flux de journalisation que nous avons activé précédemment :

$ ./waf
$ export NS_LOG=
Теперь, если вы запустите скрипт,
$ ./waf --run scratch/myfirst

Vous ne verrez pas le nouveau message car le composant de journalisation associé (FirstScriptExample) n'a pas été activé. Pour voir votre message, vous devez activer le composant de journalisation ExemplePremierScript avec un niveau non inférieur à NS_LOG_INFO. Si vous souhaitez simplement voir ce niveau de journalisation spécifique, vous pouvez l'activer comme ceci :

$ export NS_LOG=FirstScriptExample=info

Si vous exécutez le script maintenant, vous verrez un nouveau message « Création d'une topologie »,

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.404s)
Creating Topology
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.1.2

5.2 Utilisation des arguments de ligne de commande

5.2.1 Remplacement des valeurs d'attribut par défaut

Une autre façon de modifier le comportement des scripts ns-3 sans les modifier ni les créer consiste à utiliser des arguments de ligne de commande. Nous fournissons un mécanisme pour analyser les arguments de ligne de commande et définir automatiquement des variables locales et globales en fonction des résultats.

La première étape de l’utilisation du système d’arguments de ligne de commande consiste à déclarer un analyseur de ligne de commande. C'est assez simple à faire (dans votre programme principal), comme dans le code suivant,

int
main (int argc, char *argv[])
{
...
CommandLine cmd;
cmd.Parse (argc, argv);
...
}

Ce simple extrait de deux lignes est en fait très utile en soi. Il ouvre la porte au système global de variables et d’attributs ns-3. Ajoutons deux lignes de code au début de la fonction de script principale scratch/monpremier.cc. Ensuite, nous compilons le script et l'exécutons, lors de l'exécution, nous faisons une demande d'aide comme suit,

$ ./waf --run "scratch/myfirst --PrintHelp"

Cette commande demandera Waf script de lancement gratter/ma première et passez-lui un argument de ligne de commande —AideImprimer. Les guillemets sont nécessaires pour indiquer à quel programme l'argument est destiné. L'analyseur de ligne de commande détectera l'argument —AideImprimer et affichera la réponse,

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.413s)
TcpL4Protocol:TcpStateMachine()
CommandLine:HandleArgument(): Handle arg name=PrintHelp value=
--PrintHelp: Print this help message.
--PrintGroups: Print the list of groups.
--PrintTypeIds: Print all TypeIds.
--PrintGroup=[group]: Print all TypeIds of group.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintGlobals: Print the list of globals.

Voyons maintenant l'option —Attributs d'impression. Nous avons déjà évoqué le système d'attributs ns-3 lors de l'étude du script first.cc. Nous avons vu les lignes de code suivantes,

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

et ils ont dit que Débit de données est en fait un attribut PointVersPointNetDevice. Utilisons l'analyseur d'arguments de ligne de commande pour afficher les attributs PointVersPointNetDevice. La liste d'aide indique ce que nous devons fournir ID de type. Il s'agit du nom de la classe à laquelle appartiennent les attributs qui nous intéressent. Dans notre cas, ce sera ns3 :: PointToPointNetDevice. Continuons d'avancer, entrez,

$ ./waf --run "scratch/myfirst --PrintAttributes=ns3::PointToPointNetDevice"

Le système imprimera tous les attributs de ce type de périphérique réseau. Vous verrez que parmi les attributs de la liste figurent :

--ns3::PointToPointNetDevice::DataRate=[32768bps]:
The default data rate for point to point links

C'est la valeur par défaut qui sera utilisée par le système lors de la création de l'objet PointVersPointNetDevice. Nous remplacerons cette valeur par défaut en utilisant le paramètre Attribut в PointÀPointHelper plus haut. Utilisons les valeurs par défaut pour les appareils et les canaux point à point. Pour ce faire, nous supprimerons les appels DéfinirDeviceAttribute и DéfinirChannelAttribute de mapremière.cc, que nous avons dans un répertoire propre.

Votre script devrait maintenant simplement déclarer PointÀPointHelper et n'effectuez aucune opération d'installation comme indiqué dans l'exemple ci-dessous,

...
NodeContainer nodes;
nodes.Create (2);
PointToPointHelper pointToPoint;
NetDeviceContainer devices;
devices = pointToPoint.Install (nodes);
...

Allez-y et créez un nouveau script avec Waf (./waff) et revenons en arrière et incluons une entrée de l'application du serveur d'écho UDP et incluons le préfixe temporel.

$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'

Si vous exécutez le script, vous devriez voir le résultat suivant :

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.405s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Sent 1024 bytes to 10.1.1.2
2.25732s Received 1024 bytes from 10.1.1.1
2.25732s Echoing packet
Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Rappelons que la dernière fois que nous avons regardé le temps de simulation, au moment où le paquet a été reçu par le serveur d'écho, il était de 2,00369 secondes.

2.00369s UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1

Désormais, il reçoit le paquet en 2.25732 secondes. En effet, nous avons simplement réinitialisé le débit de données PointToPointNetDevice de cinq mégabits par seconde à la valeur par défaut, qui est de 32768 XNUMX bits par seconde. Si nous devions remplacer un nouveau DataRate en utilisant la ligne de commande, nous pourrions à nouveau accélérer notre simulation. Nous allons procéder de la manière suivante, selon la formule impliquée par l'élément help :

$ ./waf --run "scratch/myfirst --ns3::PointToPointNetDevice::DataRate=5Mbps"

Cela ramènera l'attribut DataRate à sa valeur par défaut de cinq mégabits par seconde. Etes-vous surpris du résultat ? Il s'avère que pour rétablir le comportement d'origine du script, nous devons également définir le délai du canal pour qu'il corresponde à la vitesse de la lumière. Nous pouvons demander au système de ligne de commande d'imprimer les attributs du canal, tout comme nous l'avons fait pour le périphérique réseau :

$ ./waf --run "scratch/myfirst --PrintAttributes=ns3::PointToPointChannel"

Nous constaterons que l'attribut de délai de canal est défini comme suit :

--ns3::PointToPointChannel::Delay=[0ns]:
Transmission delay through the channel

Nous pouvons ensuite, via le système de ligne de commande, définir ces deux valeurs par défaut.

$ ./waf --run "scratch/myfirst
--ns3::PointToPointNetDevice::DataRate=5Mbps
--ns3::PointToPointChannel::Delay=2ms"

dans ce cas, nous restaurons le temps dont nous disposions lorsque nous avons explicitement défini le DataRate et le Delay dans le script :

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.417s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Sent 1024 bytes to 10.1.1.2
2.00369s Received 1024 bytes from 10.1.1.1
2.00369s Echoing packet
Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Notez que le paquet est à nouveau reçu par le serveur après 2,00369 secondes. Nous pourrions en fait définir n'importe lequel des attributs utilisés dans le script de cette façon. En particulier, nous pourrions définir les attributs MaxPackets sur des valeurs non uniques. UdpEchoClient.

Comment l’utiliseriez-vous ? Essaie. N'oubliez pas que vous devez commenter l'endroit où nous remplaçons la valeur de l'attribut par défaut et définissons explicitement MaxPaquets dans le scénario. Ensuite, vous devez reconstruire le script. Vous pouvez également utiliser la ligne de commande pour obtenir une aide sur la syntaxe permettant de définir une nouvelle valeur d'attribut par défaut. Une fois que vous avez compris cela, vous pouvez contrôler le nombre de packages affichés sur la ligne de commande. Puisque nous sommes des gens studieux, notre ligne de commande devrait ressembler à ceci :

$ ./waf --run "scratch/myfirst
--ns3::PointToPointNetDevice::DataRate=5Mbps
--ns3::PointToPointChannel::Delay=2ms
--ns3::UdpEchoClient::MaxPackets=2"

La question naturelle qui se pose à ce stade est de savoir comment connaître l’existence de tous ces attributs. Encore une fois, le système de ligne de commande dispose d’une fonction d’aide à ce sujet. Si nous demandons de l'aide à la ligne de commande, nous devrions voir :

$ ./waf --run "scratch/myfirst --PrintHelp"
myfirst [Program Arguments] [General Arguments]
General Arguments:
--PrintGlobals: Print the list of globals.
--PrintGroups: Print the list of groups.
--PrintGroup=[group]: Print all TypeIds of group.
--PrintTypeIds: Print all TypeIds.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintHelp: Print this help message.

Si vous sélectionnez l'argument "PrintGroups", vous devriez voir une liste de tous les groupes enregistrés ID de type. Les noms de groupe sont cohérents avec les noms des modules dans le répertoire source (bien qu'en majuscules). Imprimer toutes les informations d'un coup serait trop volumineux, un filtre supplémentaire est donc disponible pour imprimer les informations par groupe. Donc, encore une fois en nous concentrant sur le module point à point :

./waf --run "scratch/myfirst --PrintGroup=PointToPoint"
TypeIds in group PointToPoint:
ns3::PointToPointChannel
ns3::PointToPointNetDevice
ns3::PointToPointRemoteChannel
ns3::PppHeader

Vous trouverez ici les noms TypeId disponibles pour les recherches d'attributs, par exemple dans
--PrintAttributes = ns3 :: PointToPointChannelComme montré ci-dessus.

Une autre façon d’en apprendre davantage sur les attributs consiste à utiliser Doxygen ns‑3. Il existe une page qui répertorie tous les attributs enregistrés dans le simulateur.

5.2.2 Capturer vos propres commandes

Vous pouvez également ajouter vos propres hooks via le système de ligne de commande. Cela se fait tout simplement en utilisant la méthode d'analyseur en ligne de commande AddValue.
Utilisons cette fonctionnalité pour spécifier le nombre de packages à afficher d'une manière complètement différente. Ajoutons une variable locale appelée nPaquets dans une fonction principal. Nous le définirons sur un pour correspondre à notre comportement par défaut précédent. Pour permettre à l'analyseur de ligne de commande de modifier cette valeur, nous devons capturer cette valeur dans l'analyseur. Nous faisons cela en ajoutant un appel AddValue. Allez changer le script scratch/monpremier.cc так, чтобы начать со следующего кода,

int
main (int argc, char *argv[])
{
uint32_t nPackets = 1;
CommandLine cmd;
cmd.AddValue("nPackets", "Number of packets to echo", nPackets);
cmd.Parse (argc, argv);
...

Faites défiler jusqu'au point du script où nous définissons l'attribut MaxPackets et modifions-le pour qu'il soit défini sur la variable nPackets au lieu de la constante 1, comme indiqué ci-dessous.

echoClient.SetAttribute ("MaxPackets", UintegerValue (nPackets));

Maintenant, si vous exécutez le script et fournissez l'argument -PrintHelp, vous devriez voir le nouvel argument utilisateur. répertoriés sur l’écran d’aide. Entrer,

$ ./waf --run "scratch/myfirst --PrintHelp"
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.403s)
--PrintHelp: Print this help message.
--PrintGroups: Print the list of groups.
--PrintTypeIds: Print all TypeIds.
--PrintGroup=[group]: Print all TypeIds of group.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintGlobals: Print the list of globals.
User Arguments:
--nPackets: Number of packets to echo

Si vous souhaitez modifier le nombre de paquets transmis, vous pouvez le faire en définissant l'argument de ligne de commande - -nPackets.

$ ./waf --run "scratch/myfirst --nPackets=2"

Maintenant tu devrais maintenant voir

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.404s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Sent 1024 bytes to 10.1.1.2
2.25732s Received 1024 bytes from 10.1.1.1
2.25732s Echoing packet
Received 1024 bytes from 10.1.1.2
Sent 1024 bytes to 10.1.1.2
3.25732s Received 1024 bytes from 10.1.1.1
3.25732s Echoing packet
Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Vous avez maintenant envoyé deux colis. Assez simple, n'est-ce pas ?
Vous pouvez voir qu'en tant qu'utilisateur NS-3, vous pouvez utiliser le système d'arguments de ligne de commande pour manipuler les valeurs et les attributs globaux. Si vous êtes l'auteur du modèle, vous pouvez ajouter de nouveaux attributs à vos objets et ils seront automatiquement disponibles pour la configuration par vos utilisateurs via le système de ligne de commande. Si vous êtes un auteur de scripts, vous pouvez ajouter de nouvelles variables à vos scripts et les intégrer de manière transparente à votre système de ligne de commande.

5.3 Utilisation du système de traçage

L’intérêt de la modélisation est de générer des résultats pour une étude plus approfondie, et le système de trace ns-3 en est le principal mécanisme. Puisque ns-3 est un programme C++, des moyens standard de génération de sortie à partir d'un programme C++ peuvent être utilisés :

#include <iostream>
...
int main ()
{
...
std::cout << "The value of x is " << x << std::endl;
...
}

Vous pouvez même utiliser un module de journalisation pour ajouter un peu de structure à votre solution. Il existe de nombreux problèmes connus causés par cette approche, c'est pourquoi nous avons fourni un sous-système général de suivi des événements pour résoudre ces problèmes.

Les principaux objectifs du système de traçage ns-3 sont :

  • Pour les tâches de base, le système de traçage doit permettre à l'utilisateur de générer une trace standard pour les sources populaires et de sélectionner les objets qui génèrent la trace ;

  • Les utilisateurs intermédiaires devraient pouvoir étendre le système de traçage pour modifier le format de sortie généré ou insérer de nouvelles sources de trace, sans modifier le cœur du simulateur ;

  • Les utilisateurs avancés peuvent modifier le noyau du simulateur pour ajouter de nouvelles sources et récepteurs de trace. Le système de traçage ns-3 repose sur les principes de sources et de récepteurs de suivi indépendants, ainsi que sur un mécanisme unifié de connexion des sources aux consommateurs.

Le système de traçage ns-3 repose sur les principes de sources et de récepteurs de traçage indépendants, ainsi que sur un mécanisme unifié de connexion des sources aux récepteurs. Les sources de trace sont des objets qui peuvent signaler des événements se produisant dans la simulation et donner accès aux données sous-jacentes d'intérêt. Par exemple, une source de trace peut indiquer quand un périphérique réseau a reçu un paquet et mettre le contenu du paquet à la disposition des récepteurs de trace intéressés.

Les sources de trace en elles-mêmes sont inutiles à moins qu'elles ne soient « couplées » à d'autres parties du code qui font réellement quelque chose d'utile avec les informations fournies par le récepteur. Les traceurs sont des consommateurs d'événements et de données fournis par les sources de trace. Par exemple, vous pouvez créer un récepteur de trace qui (une fois connecté à la source de trace de l'exemple précédent) imprimera les parties intéressantes du paquet reçu.

La raison de cette séparation explicite est de permettre aux utilisateurs de connecter de nouveaux types de récepteurs aux sources de trace existantes sans avoir à modifier et recompiler le cœur du simulateur. Ainsi, dans l'exemple ci-dessus, l'utilisateur peut définir un nouveau traceur dans son script et le connecter à une source de trace existante définie dans le noyau de simulation uniquement en éditant le script utilisateur.

Dans ce didacticiel, nous passerons en revue certaines des sources et des récepteurs prédéfinis et montrerons comment ils peuvent être configurés avec le moins d'effort de la part de l'utilisateur. Consultez le manuel ns-3 ou les sections pratiques pour obtenir des informations sur la configuration avancée de la trace, notamment l'extension de l'espace de noms de trace et la création de nouvelles sources de trace.

5.3.1 Traçage ASCII

ns-3 fournit une fonctionnalité d'assistance qui fournit un système de traçage de bas niveau pour vous aider avec les détails lors de la configuration de traces de paquets simples. Si vous activez cette fonctionnalité, vous verrez la sortie dans des fichiers ASCII. Pour ceux qui sont familiers avec la sortie ns-2, ce type de trace est similaire à out.tr, qui est généré par de nombreux scripts.

Passons aux choses sérieuses et ajoutons quelques résultats de traçage ASCII à notre script scratch/myfirst.cc. Juste avant l'appel Simulator :: Run (), ajoutez les lignes de code suivantes :
AsciiTraceHelper ascii ;

pointToPoint.EnableAsciiAll (ascii.CreateFileStream ("myfirst.tr"));

Comme beaucoup d'autres idiomes ns-3, ce code utilise un objet assistant pour créer des traces ASCII. La deuxième ligne contient deux appels de méthode imbriqués. Méthode "à l'intérieur" CréerFileStream() utilise l'idiome d'objet anonyme pour créer un objet de flux de fichiers sur la pile (sans nom d'objet) et le transmet à la méthode appelée. Nous y reviendrons plus en détail à l'avenir, mais tout ce que vous devez savoir à ce stade est que vous créez un objet qui représente un fichier appelé mapremière.tr et transférez-le sur ns-3. Nous confions à ns-3 le soin de s'occuper de l'objet créé pendant toute sa durée de vie, pendant laquelle il résout les problèmes causés par une limitation (intentionnelle) peu connue associée aux constructeurs de copie d'objets de flux C++.

Appel externe ActiverAsciiAll() indique à l'assistant que vous souhaitez inclure le suivi ASCII dans votre simulation pour toutes les connexions de périphériques point à point et que vous souhaitez que les récepteurs de suivi (spécifiés) enregistrent les informations sur les mouvements de paquets au format ASCII.

Pour ceux qui sont familiers avec NS-2, les événements suivis sont équivalents aux points de trace connus qui enregistrent les événements "+", "-", "d" et "r".
Vous pouvez maintenant créer le script et l'exécuter à partir de la ligne de commande :

$ ./waf --run scratch/myfirst

Comme plusieurs fois auparavant, vous verrez plusieurs messages de Waf, puis « la construction s'est terminée avec succès » avec quelques messages du programme en cours d'exécution.

Lors de l'exécution, le programme créera un fichier nommé mapremière.tr. En raison de la nature du travail Waf, par défaut, le fichier n'est pas créé dans le répertoire local, mais dans le répertoire de niveau supérieur du référentiel. Si vous souhaitez modifier le chemin où les traces sont enregistrées, vous pouvez utiliser le paramètre Waf pour le spécifier --cwd. Nous ne l'avons pas fait, donc pour examiner le fichier de trace ASCII myfirst.tr dans votre éditeur préféré, nous devrons accéder au répertoire de niveau supérieur de notre référentiel.

Analyse des traces ASCII

Il contient de nombreuses informations sous une forme assez dense, mais la première chose que vous devez remarquer est que le fichier est constitué de lignes individuelles. Cela deviendra clairement visible si vous agrandissez la fenêtre de visualisation.

Chaque ligne du fichier correspond à un événement de trace. Dans ce cas, nous traçons les événements dans la file d'attente de transmission présente dans chaque périphérique réseau point à point de la simulation. La file d'attente de transmission est la file d'attente par laquelle doit passer chaque paquet pour une liaison point à point. Notez que chaque ligne du fichier de trace commence par un seul caractère (et est suivie d'un espace). Ce symbole aura la signification suivante :

+ : une opération de mise en file d'attente s'est produite sur la file d'attente du périphérique ;
- : une opération de récupération d'élément s'est produite dans la file d'attente du périphérique ;
d : le paquet a été abandonné, généralement parce que la file d'attente était pleine ;
r : Le paquet a été reçu par un périphérique réseau.

Examinons de plus près la première ligne du fichier de trace. Je vais le décomposer en parties (avec des indentations pour plus de clarté) et le numéro de ligne sur la gauche :

0 +
1 2
2 /NodeList/0/DeviceList/0/$ns3::PointToPointNetDevice/TxQueue/Enqueue
3 ns3::PppHeader (
4   Point-to-Point Protocol: IP (0x0021))
6   ns3::Ipv4Header (
7     tos 0x0 ttl 64 id 0 protocol 17 offset 0 flags [none]
8     length: 1052 10.1.1.1 > 10.1.1.2)
9     ns3::UdpHeader (
10      length: 1032 49153 > 9)
11      Payload (size=1024)

La première section de cet événement de trace étendue (ligne 0) est l'opération. Nous avons ici un symbole +, qui correspond à l'opération de mise en file d'attente pour la transmission. La deuxième section (ligne 1) est le temps de simulation, exprimé en secondes. Vous vous souvenez peut-être de ce que nous avons demandé UdpEchoClientApplicationUdpEchoClientApplication commencez à envoyer des paquets dans deux secondes. Nous voyons ici la confirmation que cela est effectivement en train de se produire.

La section suivante de l'exemple de trace (à partir de la ligne 2) montre quelle source de trace a généré cet événement (indiquant la trace de l'espace de noms). Vous pouvez considérer l’espace de noms de trace comme vous le feriez pour un espace de noms de système de fichiers. La racine de l'espace de noms est Liste de nœuds. Это соответствует контейнеру, управляемому в основном коде ns‑3. В нем содержатся все узлы, которые создаются в скрипте. Так же, как файловая система может иметь в корне директории, в Liste de nœuds nous pouvons avoir plusieurs nœuds. Ainsi, la ligne /NodeList/0 fait référence au nœud nul dans la NodeList, que nous appelons généralement « nœud 0 ». Chaque nœud possède une liste de périphériques installés. Cette liste se trouve ensuite dans l'espace de noms. Vous pouvez voir que cet événement de trace provient Liste des appareils/0, qui est le périphérique nul installé dans le nœud.

Sous-chaîne suivante, $ ns3 :: PointToPointNetDevice, indique quel périphérique est à la position zéro : la liste des périphériques du nœud zéro. Rappelons que l'opération + trouvée à la ligne 0 signifiait qu'un élément était ajouté à la file d'attente de transmission de l'appareil. Cela se reflète dans les derniers segments du « chemin de piste » : TxQueue/Mise en file d'attente.

Les sections restantes de la trace doivent être assez intuitives. Les lignes 3 à 4 indiquent que le paquet est encapsulé dans un protocole point à point. Les lignes 5 à 7 montrent que le paquet a un en-tête de version IP4 et provient de l'adresse IP. 10.1.1.1 et est destiné à 10.1.1.2. Les lignes 8 à 9 montrent que ce paquet a un en-tête UDP et enfin la ligne 10 montre que la charge utile correspond aux 1024 XNUMX octets attendus.

La ligne suivante du fichier de trace montre que le même paquet a été extrait de la file d'attente de transmission sur le même nœud.

La troisième ligne du fichier de trace indique que le paquet a été reçu par un périphérique réseau sur l'hôte du serveur d'écho. J'ai reproduit l'événement ci-dessous.

0 r
1 2.25732
2 /NodeList/1/DeviceList/0/$ns3::PointToPointNetDevice/MacRx
3   ns3::Ipv4Header (
4     tos 0x0 ttl 64 id 0 protocol 17 offset 0 flags [none]
5     length: 1052 10.1.1.1 > 10.1.1.2)
6     ns3::UdpHeader (
7       length: 1032 49153 > 9)
8       Payload (size=1024)

Notez que l'opération de trace est désormais r et que le temps de simulation a été augmenté à 2,25732 secondes. Si vous avez suivi attentivement le didacticiel, cela signifie que vous avez laissé le DataRate et le Link Delay des périphériques réseau à leurs valeurs par défaut. Ce temps devrait être familier, comme vous l'avez vu dans la section précédente.

L'entrée de l'espace de noms de la source de trace (ligne 2) a été modifiée pour indiquer que cet événement provient du nœud 1 (/Liste de nœuds/1) et le paquet est reçu par la source de trace (/MacRx). Il devrait être assez facile pour vous de suivre le mouvement du paquet dans la topologie en examinant les traces restantes dans le fichier.

5.3.2 Suivi du PPCE

Les Device Helpers ns-3 peuvent également être utilisés pour créer des fichiers de trace au format .pcap. Acronyme pcap (généralement écrit en minuscules) signifie capture de paquets et est en fait une API qui inclut la définition du format de fichier .pcap. Le programme le plus populaire capable de lire et d'afficher ce format est Wireshark (anciennement appelé Éthéré). Cependant, de nombreux analyseurs de trace de trafic utilisent ce format de paquet. Nous encourageons les utilisateurs à utiliser les nombreux outils disponibles pour analyser les traces pcap. Dans ce didacticiel, nous nous concentrerons sur l'affichage des traces pcap à l'aide de tcpdump.

L'activation du traçage pcap se fait avec une seule ligne de code.

pointToPoint.EnablePcapAll ("myfirst");

Collez cette ligne de code après le code de trace ASCII que nous venons d'ajouter scratch/monpremier.cc. Notez que nous n'avons transmis que la chaîne "myfirst", pas "myfirst.pcap" ou quelque chose de similaire. En effet, le paramètre est un préfixe et non un nom de fichier complet. Lors de la simulation, l'assistant va en fait créer un fichier de trace pour chaque appareil point à point. Les noms de fichiers seront construits en utilisant le préfixe, le numéro de nœud, le numéro de périphérique et le suffixe ".pcap».

Для нашего примера сценария мы в конечном итоге увидим файлы с именами «monpremier-0-0.pcap"Et"monpremier-1-0.pcap", qui sont des traces pcap pour le nœud 0-périphérique 0 et le nœud 1-périphérique 0 respectivement. Une fois que vous avez ajouté la ligne de code pour activer le traçage pcap, vous pouvez exécuter le script de la manière habituelle :

$ ./waf --run scratch/myfirst

Si vous regardez dans le répertoire de niveau supérieur de votre distribution, vous devriez voir trois fichiers : un fichier de trace ASCII mapremière.tr, que nous avons étudié précédemment, classe monpremier-0-0.pcap и monpremier-1-0.pcap - les nouveaux fichiers pcap que nous venons de générer.

Lecture de la sortie avec tcpdump

Pour l’instant, le moyen le plus simple d’afficher les fichiers pcap consiste à utiliser tcpdump.

$ tcpdump -nn -tt -r myfirst-0-0.pcap
reading from file myfirst-0-0.pcap, link-type PPP (PPP)
2.000000 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, length 1024
2.514648 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, length 1024
tcpdump -nn -tt -r myfirst-1-0.pcap
reading from file myfirst-1-0.pcap, link-type PPP (PPP)
2.257324 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, length 1024
2.257324 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, length 1024

Dans la décharge monpremier-0-0.pcap (appareil client), vous pouvez voir que le paquet d'écho est envoyé après 2 secondes de simulation. Si vous regardez le deuxième dump (monpremier-1-0.pcap), vous verrez que le paquet est reçu à 2,257324 secondes. Vous verrez dans le deuxième vidage que le paquet est renvoyé à 2.257324 secondes, et enfin que le paquet a été reçu par le client lors du premier vidage à 2.514648 secondes.

Lecture de la sortie avec Wireshark

сли вы не знакомы с Wireshark, il existe un site Web sur lequel vous pouvez télécharger des programmes et de la documentation : http://www.wireshark.org/. Wireshark est une interface graphique qui peut être utilisée pour afficher ces fichiers de trace. Si vous disposez de Wireshark, vous pouvez ouvrir n'importe lequel des fichiers de trace et afficher le contenu comme si vous aviez capturé les paquets à l'aide d'un renifleur de paquets.

Source: habr.com

Ajouter un commentaire