5 Configuration
5.1 Using the Logging Module
5.1.1 Overview of Logging
5.1.2 Enabling Logging
5.1.3 Adding Logging to Your Code
5.2 Using Command Line Arguments
5.2.1 Overriding Default Attribute Values
5.2.2 Capturing Your Own Commands
5.3 Using the Tracing System
5.3.1 ASCII Tracing
Parsing ASCII Traces
5.3.2 PCAP Tracing
Chapitre 5
Configuration
5.1 Using the Logging Module
We have briefly examined the ns-3 logging module while reviewing the script. first.ccIn this chapter, we will take a closer look at the options for using the logging subsystem.
5.1.1 Overview of Logging
Many large systems support some form of message logging, and ns-3 is no exception. In some cases, only error messages are written to the 'operator console' (which is usually stderr in Unix-based systems). In other systems, warning messages as well as more detailed information may be output. In certain cases, logging tools are used to output debug messages that can quickly 'blur' the output.
The approach used in ns-3 assumes that all of these levels of verbosity are useful, and we provide a selective, multi-level approach to message logging. Logging can be completely disabled, enabled for individual components, or on a global scale. Customizable verbosity levels serve this purpose. The ns-3 logging module provides a relatively simple way to obtain useful information from your simulation.
You should understand that we provide a general-purpose mechanism - tracing - for extracting data from your models, which should be preferred for output during modeling (for more details on our tracing system, see section 5.3 of the tutorial). Logging should be the preferred method for obtaining debug information, warnings, error messages, or for quickly outputting messages from your scripts or models at any time.
Currently, the system defines seven levels (types) of log messages in increasing order of verbosity.
- LOG_ERROR — logging error messages (related macro: NS_LOG_ERROR);
- LOG_WARN — enregistrement des messages d'avertissement (macro associée : NS_LOG_WARN);
- LOG_DEBUG — enregistrement des messages de débogage 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 — enregistrement des messages décrivant chaque fonction appelée (deux macros associées : NS_LOG_FUNCTION, utilisé pour les fonctions membres, et NS_LOG_FUNCTION_NOARGS, utilisé pour les fonctions statiques);
- LOG_LOGIC — enregistrement des messages décrivant le flux logique à l'intérieur de la fonction (macro associée : NS_LOG_LOGIC);
- LOG_ALL — enregistrement de tout ce qui précède (aucune macro associée).
Pour chaque type (LOG_TYPE), il existe également un type LOG_LEVEL_TYPE qui, s'il est utilisé, permet d'enregistrer, en plus de son propre niveau, tous les niveaux au-dessus de lui. (En conséquence, LOG_ERROR et LOG_LEVEL_ERROR, ainsi que LOG_ALL et LOG_LEVEL_ALL sont fonctionnellement équivalents.) Par exemple, l'activation de LOG_INFO n'autorisera que les messages fournis par la macro NS_LOG_INFO, tandis qu'avec LOG_LEVEL_INFO, les messages fournis par les macros NS_LOG_DEBUG, NS_LOG_WARN et NS_LOG_ERROR seront également inclus.
Nous fournissons également une macro d'enregistrement inconditionnelle qui s'affiche toujours, indépendamment du niveau de journal ou du composant sélectionné.
- NS_LOG_UNCOND — enregistrement inconditionnel du message associé (sans niveau de journal associé).
Chaque niveau peut être demandé séparément ou cumulé. Le journal peut être configuré à l'aide de la variable d'environnement sh : NS_LOG ou en enregistrant un appel à la fonction système. Comme mentionné précédemment, le système de journalisation a une documentation Doxygen et c'est le bon moment pour la consulter si ce n'est pas encore 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/myfirst.cc, que vous avez déjà compilé.
5.1.2 Enabling Logging
Utilisons la variable d'environnement NS_LOG pour lancer quelques journaux supplémentaires, mais d'abord, juste pour se repérer, exécutez le dernier script comme vous l'avez fait précédemment,
$ ./waf --run scratch/myfirstVous devriez voir la sortie déjà familière du premier programme exemple ns‑3.
$ Waf: Entrée dans le dossier `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Sortie du dossier `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build` 'build'
fini avec succès (0.413s)
Envoyé 1024 octets à 10.1.1.2
Reçu 1024 octets de 10.1.1.1
Reçu 1024 octets de 10.1.1.2Il s'avère que les messages « envoyés » et « reçus » que vous voyez ci-dessus sont en fait des messages enregistrés de UdpEchoClientApplication et UdpEchoServerApplication. Par exemple, nous pouvons demander à l'application cliente d'imprimer des informations supplémentaires en définissant son niveau de journalisation via la variable d'environnement NS_LOG.
À partir de ce moment, je vais supposer que vous utilisez un shell de type sh qui utilise la syntaxe « VARIABILE = valeur ». Si vous utilisez un shell de type csh, vous devrez adapter mes exemples à la syntaxe « setenv variable valeur » requise par ces shells.
Actuellement, l'application UDP echo client répond à la ligne de code suivante dans scratch/myfirst.cc,
LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);Cela active le niveau de journalisation LOG_LEVEL_INFO. Lorsque nous passons le drapeau de niveau de journalisation, nous activons en réalité ce niveau et 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 modifier le script ni le recompiler, en définissant la variable d'environnement NS_LOG comme suit :
$ export NS_LOG=UdpEchoClientApplication=level_allAinsi, nous définissons la valeur suivante de la variable NS_LOG dans le shell sh,
UdpEchoClientApplication=level_allLe côté gauche de l'assignation est le nom du composant enregistré que nous souhaitons configurer, et le côté droit est le drapeau que nous voulons 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 configuré de cette manière, le système de journalisation ns-3 prendra en compte les modifications et vous devriez voir la sortie suivante :
Waf: Entrée dans le dossier `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Sortie du dossier `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
'build' fini avec succès (0.404s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
Envoyé 1024 octets à 10.1.1.2
Reçu 1024 octets de 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
Reçu 1024 octets de 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()Les informations de débogage supplémentaires fournies par l'application correspondent désormais au niveau NS_LOG_FUNCTION. Elles montrent chaque appel de fonction pendant l'exécution du script. En général, il est préférable d'utiliser (au minimum)NS_LOG_FUNCTION (this). Utilisez NS_LOG_FUNCTION_NOARGS ()
uniquement dans les fonctions statiques. Cependant, il convient de noter qu'il n'y a pas d'exigences dans le système ns‑3 concernant le maintien d'une quelconque fonctionnalité de journalisation. La décision de la quantité d'informations à enregistrer revient au développeur du modèle. En ce qui concerne les applications écho, une grande quantité de sorties est disponible pour la journalisation.
Vous pouvez désormais consulter le journal des appels de fonctions effectués par l'application. Si vous regardez attentivement, vous remarquerez un deux-points entre la ligne UdpEchoClientApplication et le nom de la méthode, à l'endroit où vous vous attendiez peut-être à voir l'opérateur de portée C++ (::). Cela a été fait intentionnellement.
En fait, ce n'est pas le nom de la classe, mais le nom du composant de journalisation. Lorsqu'il y a une correspondance entre le fichier source et la classe, il s'agit généralement du nom de la classe, mais vous devez comprendre qu'il ne s'agit pas réellement du nom de la classe, et qu'il y a un seul deux-points au lieu de deux. C'est un moyen de vous aider, de manière relative, à séparer conceptuellement le nom du composant de journalisation du nom de la classe.
Cependant, dans certains cas, il peut être difficile de déterminer quel méthode génère réellement le message de journal. Si vous regardez le texte ci-dessus, vous pourriez vous demander d'où provient la ligne «Received 1024 bytes from 10.1.1.2». Vous pouvez résoudre ce problème en définissant le niveau prefix_func dans la variable d'environnement NS_LOG. Essayez de faire ce qui suit,
$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'Notez que les guillemets sont nécessaires, car le barre verticale que nous utilisons pour indiquer l'opération OU est également un séparateur de pipeline Unix. Maintenant, si vous exécutez le script, vous verrez que le système de journalisation garantit que chaque message provenant de ce journal a un préfixe avec le nom du composant.
Waf : Entrée dans le répertoire `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`\nWaf : Sortie du répertoire `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`\n`build` terminé avec succès (0.417s)\nUdpEchoClientApplication:UdpEchoClient()\nUdpEchoClientApplication:SetDataSize(1024)\nUdpEchoClientApplication:StartApplication()\nUdpEchoClientApplication:ScheduleTransmit()\nUdpEchoClientApplication:Send()\nUdpEchoClientApplication:Send(): A envoyé 1024 octets à 10.1.1.2\nReçu 1024 octets de 10.1.1.1\nUdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)\nUdpEchoClientApplication:HandleRead(): Reçu 1024 octets de 10.1.1.2\nUdpEchoClientApplication:StopApplication()\nUdpEchoClientApplication:DoDispose()\nUdpEchoClientApplication:~UdpEchoClient()Vous pouvez maintenant voir que tous les messages provenant de l'application UDP écho-client sont identifiés comme tels. Le message «Received 1024 bytes from 10.1.1.2» est maintenant clairement défini comme provenant de l'application écho-client. Le message restant doit provenir de l'application UDP écho-serveur. Nous pouvons activer ce composant en entrant une liste de composants séparés par des deux-points dans la variable d'environnement NS_LOG.
$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func:\n UdpEchoServerApplication=level_all|prefix_func'Avertissement : Dans l'exemple de texte ci-dessus, vous devrez supprimer le caractère de nouvelle ligne après le deux-points (:), il est utilisé pour formater le document. Maintenant, si vous lancez le script, vous verrez tous les messages du journal provenant des applications écho-clients et écho-serveurs. Vous constaterez que cela peut être très utile pour le débogage.
Waf : Entrée dans le répertoire `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`\nWaf : Sortie du répertoire `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`\n`build` terminé avec succès (0.406s)\nUdpEchoServerApplication:UdpEchoServer()\nUdpEchoClientApplication:UdpEchoClient()\nUdpEchoClientApplication:SetDataSize(1024)\nUdpEchoServerApplication:StartApplication()\nUdpEchoClientApplication:StartApplication()\nUdpEchoClientApplication:ScheduleTransmit()\nUdpEchoClientApplication:Send()\nUdpEchoClientApplication:Send(): A envoyé 1024 octets à 10.1.1.2\nUdpEchoServerApplication:HandleRead(): Reçu 1024 octets de 10.1.1.1\nUdpEchoServerApplication:HandleRead(): Écho du paquet\nUdpEchoClientApplication:HandleRead(0x624920, 0x625160)\nUdpEchoClientApplication:HandleRead(): Reçu 1024 octets de 10.1.1.2\nUdpEchoServerApplication:StopApplication()\nUdpEchoClientApplication:StopApplication()\nUdpEchoClientApplication:DoDispose()\nUdpEchoServerApplication:DoDispose()\nUdpEchoClientApplication:~UdpEchoClient()\nUdpEchoServerApplication:~UdpEchoServer()Il est également parfois utile de pouvoir voir le temps de simulation auquel le message du journal a été généré. Vous pouvez faire cela en ajoutant un bit de préfixe prefix_time:
$ 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 la sortie suivante :
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)
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() : Envoyé 1024 octets à 10.1.1.2
2.00369s UdpEchoServerApplication : HandleRead() : Reçu 1024 octets de 10.1.1.1
2.00369s UdpEchoServerApplication : HandleRead() : Renvoie le paquet
2.00737s UdpEchoClientApplication : HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication : HandleRead() : Reçu 1024 octets de 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 fait avant le début de la simulation, mais ce temps est affiché comme zéro seconde. Il en va de même pour le message du constructeur UdpEchoClient.
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)
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() : Envoyé 1024 octets à 10.1.1.2
2.00369s UdpEchoServerApplication : HandleRead() : Reçu 1024 octets de 10.1.1.1
2.00369s UdpEchoServerApplication : HandleRead() : Renvoie le paquet
2.00737s UdpEchoClientApplication : HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication : HandleRead() : Reçu 1024 octets de 10.1.1.2
10s UdpEchoServerApplication : StopApplication()
10s UdpEchoClientApplication : StopApplication()
UdpEchoClientApplication : DoDispose()
UdpEchoServerApplication : DoDispose()
UdpEchoClientApplication : ~UdpEchoClient()
UdpEchoServerApplication : ~UdpEchoServer()Rappelons que le script scratch/first.cc a lancé l'application du serveur écho une seconde avant le début de la simulation. Maintenant, vous pouvez voir que la méthode StartApplication du serveur est effectivement appelée à la première seconde. Vous pouvez également noter que le client écho se lance à la deuxième seconde de la simulation, comme nous l'avons demandé dans le script.
Vous pouvez maintenant suivre le déroulement de la simulation en appelant ScheduleTransmit dans le client, qui appelle la fonction Send pour le rappel HandleRead dans l'application du serveur écho. Notez que le temps écoulé pour envoyer un paquet via le lien point-à-point est de 3,69 millisecondes. Il est clair que le serveur écho enregistre un message indiquant qu'il a répondu au paquet, puis, après un délai de transmission, vous voyez que le client écho reçoit le paquet écho dans sa méthode HandleRead.
Dans cette simulation, beaucoup se passe sans que vous vous en rendiez compte. Mais vous pouvez très facilement suivre tout le processus en activant tous les composants de journalisation du système. Essayez d'assigner la valeur suivante à la variable NS_LOG :
$ 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 activera tous les enregistrements dans tous les composants utilisés dans la simulation. Je ne reproduirai pas la sortie ici (au moment de la rédaction, elle génère 1265 lignes de sortie pour un seul paquet écho), mais vous pouvez rediriger ces informations dans un fichier et les visualiser dans votre éditeur préféré.
$ ./waf --run scratch/myfirst > log.out 2>&1J'utilise personnellement cette version extrêmement verbeuse du journal lorsque j'ai un problème et que je n'ai aucune idée de l'origine du soucis. Je peux suivre facilement l'exécution du code, sans avoir à mettre des points d'arrêt ou à pas à pas dans le débogueur. Je peux simplement éditer la sortie dans mon éditeur préféré et chercher ce que j'attends, ainsi que voir ce qui se passe ne correspond pas à mes attentes. Lorsque j'ai une idée générale de ce qui ne va pas, je passe au débogueur pour examiner le problème en détail. Ce type de sortie peut être particulièrement utile lorsque votre script fait quelque chose de totalement inattendu. Si vous n'utilisez que le débogueur, vous pourriez complètement rater un retournement inattendu. Les journaux rendent ces retournements visibles.
5.1.3 Adding Logging to Your Code
Vous pouvez ajouter de nouvelles entrées à vos simulations en appelant le composant log depuis plusieurs macros. Faisons cela dans le script myfirst.cc, que nous avons dans un répertoire « propre ». Rappelons que nous avons défini dans ce script le composant de journalisation :
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. Continuons et ajoutons quelques entrées au script. La macro utilisée pour ajouter des messages de niveau d'information au journal est NS_LOG_INFO. Ajoutons un message (juste avant de commencer à créer les nœuds) qui vous informe que le script est en train de créer la topologie ("Creating Topology"). Cela se fait dans l'extrait de code suivant,
Ouvrez scratch/myfirst.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);Maintenant, compilez le script en utilisant waf, et réinitialisez la variable NS_LOG pour désactiver le flux de journalisation que nous avons activé précédemment :
$ ./waf
$ export NS_LOG=
Maintenant, si vous exécutez le script,
$ ./waf --run scratch/myfirstvous 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 FirstScriptExample à un niveau égal ou supérieur à NS_LOG_INFO. Si vous voulez simplement voir ce niveau particulier de journalisation, vous pouvez l'activer ainsi,
$ export NS_LOG=FirstScriptExample=infoSi vous lancez le script maintenant, vous verrez le nouveau message "Creating Topology".
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.404s)
Creating Topology
1024 octets envoyés à 10.1.1.2
1024 octets reçus de 10.1.1.1
1024 octets reçus de 10.1.1.25.2 Using Command Line Arguments
5.2.1 Overriding Default Attribute Values
Une autre façon de modifier le comportement des scripts ns-3 sans les éditer ni les compiler est d'utiliser des arguments de ligne de commande. Nous fournissons un mécanisme pour analyser les arguments de ligne de commande et configurer automatiquement des variables locales et globales en fonction des résultats.
La première étape pour utiliser le système d'arguments de ligne de commande est de déclarer un analyseur de ligne de commande. Cela peut être fait assez simplement (dans votre programme principal), comme dans le code suivant :
int
main (int argc, char *argv[])
{
...
CommandLine cmd;
cmd.Parse (argc, argv);
...
}Ce petit fragment de deux lignes est en fait très utile en soi. Il ouvre la porte à la variable globale ns-3 et au système d'attributs. Ajoutons deux lignes de code au début de la fonction principale du script. scratch/myfirst.cc. Ensuite, compilons le script et exécutons-le, lors de l'exécution, en demandant de l'aide de la manière suivante :
$ ./waf --run "scratch/myfirst --PrintHelp"Cette commande demandera Waf d'exécuter le script scratch/myfirst et de lui passer un argument de ligne de commande --PrintHelp. Les guillemets sont nécessaires pour indiquer à quel programme l'argument est destiné. L'analyseur de ligne de commande reconnaîtra l'argument --PrintHelp et produira une réponse.
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.413s)
TcpL4Protocol:TcpStateMachine()
CommandLine:HandleArgument(): Gestion de l'argument name=PrintHelp value=
--PrintHelp: Affiche ce message d'aide.
--PrintGroups: Affiche la liste des groupes.
--PrintTypeIds: Affiche tous les TypeIds.
--PrintGroup=[group]: Affiche tous les TypeIds du groupe.
--PrintAttributes=[typeid]: Affiche tous les attributs du typeid.
--PrintGlobals: Affiche la liste des globals.Examinons maintenant l'option --PrintAttributes. Nous avons déjà mentionné 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 avons dit que DataRate est en réalité un attribut PointToPointNetDevice. Appliquons l'analyseur d'arguments de ligne de commande pour consulter les attributs. PointToPointNetDevice. La liste d'aide indique que nous devons fournir TypeId. C'est le nom de la classe à laquelle appartiennent les attributs d'intérêt. 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, il y a
--ns3::PointToPointNetDevice::DataRate=[32768bps]:
Le débit de données par défaut pour les liens point à pointC'est la valeur par défaut qui sera utilisée par le système lors de la création de l'objet PointToPointNetDevice. Nous allons redéfinir cette valeur par défaut avec le paramètre Attribut dans PointToPointHelper ci-dessus. Utilisons les valeurs par défaut pour les dispositifs et canaux point à point. Pour ce faire, supprimons les appels SetDeviceAttribute et SetChannelAttribute de myfirst.cc, que nous avons dans le répertoire vierge.
Votre script doit maintenant simplement déclarer PointToPointHelper et ne pas effectuer d'opérations d'installation, comme illustré dans l'exemple ci-dessous,
...
NodeContainer nodes;
nodes.Create (2);
PointToPointHelper pointToPoint;
NetDeviceContainer devices;
devices = pointToPoint.Install (nodes);
...Continuez et créez un nouveau script avec Waf (.\/waf) et revenons en arrière pour activer certains journaux de l'application serveur UDP echo et inclure un préfixe de temps.
$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'Si vous exécutez le script, vous devriez voir la sortie suivante :
Waf : Entrée dans le répertoire `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\nWaf : Sortie du répertoire `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\n'build' terminé avec succès (0.405s)\n0s UdpEchoServerApplication:UdpEchoServer()\n1s UdpEchoServerApplication:StartApplication()\n1024 octets envoyés à 10.1.1.2\n2.25732s 1024 octets reçus de 10.1.1.1\n2.25732s Écho du paquet\n1024 octets reçus de 10.1.1.2\n10s UdpEchoServerApplication:StopApplication()\nUdpEchoServerApplication:DoDispose()\nUdpEchoServerApplication:~UdpEchoServer()Rappelons que la dernière fois, lorsque nous avons examiné le temps de simulation, le moment de réception du paquet par le serveur echo était à 2,00369 secondes.
2.00369s UdpEchoServerApplication:HandleRead(): 1024 octets reçus de 10.1.1.1Maintenant, il reçoit le paquet à 2.25732 secondes. C'est parce que nous avons simplement réduit le débit de données de PointToPointNetDevice de cinq mégabits par seconde à la valeur par défaut de 32768 bits par seconde. Si nous avions fourni un nouveau DataRate via la ligne de commande, nous aurions pu accélérer à nouveau notre modélisation. Nous ferons cela comme suit, conformément à la formule implicite de l'élément d'aide :
$ .\/waf --run "scratch\/myfirst --ns3::PointToPointNetDevice::DataRate=5Mbps"En conséquence, la valeur par défaut de l'attribut DataRate reviendra à cinq mégaoctets par seconde. Êtes-vous surpris par ce résultat ? Il s'avère que pour restaurer le comportement initial du script, nous devons également établir la latence du canal correspondant à 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 dispositif réseau :
$ .\/waf --run "scratch\/myfirst --PrintAttributes=ns3::PointToPointChannel"Nous découvrirons que l'attribut de latence du canal est configuré comme suit :
--ns3::PointToPointChannel::Delay=[0ns]:
Délai de transmission à travers le canalEnsuite, nous pouvons définir les deux valeurs par défaut via le système de ligne de commande,
$ .\/waf --run "scratch\/myfirst
--ns3::PointToPointNetDevice::DataRate=5Mbps
--ns3::PointToPointChannel::Delay=2ms"Dans ce cas, nous restaurons le temps que nous avions lorsque nous avons explicitement défini DataRate et Delay dans le script :
Waf : Entrez dans le répertoire `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf : Quitter le répertoire `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' terminé avec succès (0.417s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
1024 octets envoyés à 10.1.1.2
2.00369s 1024 octets reçus de 10.1.1.1
2.00369s Paquet en écho
1024 octets reçus de 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()Remarquez que le paquet a de nouveau été reçu par le serveur après 2,00369 secondes. Nous pourrions réellement définir de cette manière n'importe lequel des attributs utilisés dans le scénario. En particulier, nous pourrions définir des valeurs différentes de l'unité pour les attributs MaxPackets. UdpEchoClient.
Comment utiliseriez-vous cela ? Essayez. N'oubliez pas que vous devez commenter l'endroit où nous redéfinissons la valeur par défaut de l'attribut et l'établir explicitement MaxPackets dans le script. Ensuite, vous devrez reconstruire le script. Vous pouvez également obtenir de l'aide sur la syntaxe pour définir une nouvelle valeur par défaut de l'attribut via la ligne de commande. Une fois que vous aurez compris cela, vous serez capable de gérer le nombre de paquets affichés dans la ligne de commande. Puisque nous sommes des gens sérieux, notre ligne de commande devrait ressembler à quelque chose comme ceci :
$ .\/waf --run "scratch\/myfirst
--ns3::PointToPointNetDevice::DataRate=5Mbps
--ns3::PointToPointChannel::Delay=2ms
--ns3::UdpEchoClient::MaxPackets=2"La question naturelle qui se pose ici 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 à cet égard. 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: Imprimer la liste des globales.
--PrintGroups: Imprimer la liste des groupes.
--PrintGroup=[group]: Imprimer tous les TypeIds du groupe.
--PrintTypeIds: Imprimer tous les TypeIds.
--PrintAttributes=[typeid]: Imprimer toutes les attributs du typeid.
--PrintHelp: Imprimer ce message d'aide.Si vous choisissez l'argument «PrintGroups», vous devez voir la liste de tous les groupes enregistrés. TypeId. Les noms des groupes correspondent aux noms des modules dans le répertoire source (même avec une majuscule). Imprimer toutes les informations à la fois serait trop volumineux, il est donc disponible un filtre supplémentaire pour imprimer les informations par groupes. Ainsi, en se concentrant à nouveau sur le module «point à point» :
./waf --run "scratch/myfirst --PrintGroup=PointToPoint"
TypeIds dans le groupe PointToPoint:
ns3::PointToPointChannel
ns3::PointToPointNetDevice
ns3::PointToPointRemoteChannel
ns3::PppHeaderIci, vous pouvez trouver les noms TypeId disponibles pour rechercher des attributs, par exemple, dans
--PrintAttributes = ns3::PointToPointChannel, comme indiqué ci-dessus.
Une autre façon de découvrir des attributs est via Doxygen ns-3. Il y a une page qui énumère tous les attributs enregistrés dans le simulateur.
5.2.2 Capturing Your Own Commands
Vous pouvez également ajouter vos propres hooks via le système de ligne de commande. Cela se fait assez facilement avec la méthode du parseur de ligne de commande. AddValue.
Utilisons cette possibilité pour spécifier le nombre de paquets à afficher, d'une manière complètement différente. Ajoutons une variable locale nommée nPackets dans la fonction main. Nous allons l'initialiser à un pour correspondre à notre comportement par défaut précédent. Pour permettre au parseur de ligne de commande de modifier cette valeur, nous devons capturer cette valeur dans le parseur. Nous faisons cela en ajoutant un appel AddValue. Allez et modifiez le script scratch/myfirst.cc de manière à commencer avec le code suivant :
int
main (int argc, char *argv[])
{
uint32_t nPackets = 1;
CommandLine cmd;
cmd.AddValue("nPackets", "Nombre de paquets à echo", nPackets);
cmd.Parse (argc, argv);
...Faites défiler jusqu'à l'endroit dans le script où nous définissons l'attribut MaxPackets et modifiez-le pour qu'il utilise 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 passez l'argument --PrintHelp, vous devriez voir le nouvel argument utilisateur listé à l'affichage d'aide. Entrez,
$ .\/waf --run "scratch\/myfirst --PrintHelp"
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.403s)
--PrintHelp : Affiche ce message d'aide.
--PrintGroups : Affiche la liste des groupes.
--PrintTypeIds : Affiche tous les TypeIds.
--PrintGroup=[group] : Affiche tous les TypeIds du groupe.
--PrintAttributes=[typeid] : Affiche tous les attributs du typeid.
--PrintGlobals : Affiche la liste des globals.
Arguments utilisateur :
--nPackets : Nombre de paquets à échoSi vous souhaitez modifier le nombre de paquets envoyés, vous pouvez le faire en définissant l'argument -nPackets dans la ligne de commande.
$ .\/waf --run "scratch\/myfirst --nPackets=2"Vous devriez maintenant voir
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.404s)
0s UdpEchoServerApplication : UdpEchoServer()
1s UdpEchoServerApplication : Démarrer l'application()
1024 octets envoyés à 10.1.1.2
2.25732s Reçu 1024 octets de 10.1.1.1
2.25732s Écho du paquet
Reçu 1024 octets de 10.1.1.2
1024 octets envoyés à 10.1.1.2
3.25732s Reçu 1024 octets de 10.1.1.1
3.25732s Écho du paquet
Reçu 1024 octets de 10.1.1.2
10s UdpEchoServerApplication : Arrêter l'application()
UdpEchoServerApplication : Faire le nettoyage()
UdpEchoServerApplication : ~UdpEchoServer()Vous avez maintenant envoyé deux paquets. Assez simple, n'est-ce pas ?
Vous pouvez voir qu'en tant qu'utilisateur de ns-3, vous pouvez utiliser le système d'arguments de ligne de commande pour contrôler les valeurs globales et les attributs. Si vous êtes l'auteur du modèle, vous pouvez ajouter de nouveaux attributs à vos objets, et ils seront automatiquement accessibles pour être configurés par vos utilisateurs via le système de ligne de commande. Si vous êtes l'auteur du script, vous pouvez ajouter de nouvelles variables à vos scripts et les connecter sans douleur au système de ligne de commande.
5.3 Using the Tracing System
Le but de la modélisation est de générer des données de sortie pour une étude ultérieure, et le système de trace de ns-3 est le principal mécanisme pour cela. Puisque ns-3 est un programme en C++, les outils standards de génération de sortie pour les programmes en C++ peuvent être utilisés :
#include <iostream>
...
int main ()
{
...
std::cout << "The value of x is " << x << std::endl;
...
}Vous pouvez même utiliser le module de journalisation pour ajouter un peu de structure à votre solution. De nombreux problèmes sont connus pour être causés par cette approche et c'est pourquoi nous avons fourni un sous-système commun pour la traçabilité des événements.
Les principaux objectifs du système de traçabilité ns-3 :
Pour les tâches de base, le système de traçabilité doit permettre à l'utilisateur de générer une traçabilité standard pour les sources populaires et de sélectionner les objets qui génèrent la traçabilité.
Les utilisateurs intermédiaires doivent pouvoir étendre le système de traçage pour modifier le format de sortie généré ou pour insérer de nouvelles sources de traçage, sans modifier le noyau du simulateur.
Les utilisateurs expérimentés peuvent modifier le noyau du simulateur pour ajouter de nouvelles sources et récepteurs de traçage. Le système de traçage ns-3 est construit sur les principes de sources et de récepteurs de suivi indépendants, ainsi qu'un mécanisme unifié pour connecter les sources aux consommateurs.
Le système de traçage ns-3 est basé sur les principes de sources et de récepteurs de traçage indépendants, ainsi qu'un mécanisme unifié pour connecter les sources aux récepteurs. Les sources de traçage sont des objets capables de signaler des événements se produisant dans la simulation et de fournir un accès aux données de base d'intérêt. Par exemple, une source de traçage peut indiquer quand un appareil réseau reçoit un paquet et offre un accès au contenu du paquet pour les récepteurs de traçage intéressés.
Les sources de traçage sont elles-mêmes inutiles si elles ne sont pas "connectées" à d'autres parties du code qui effectuent réellement quelque chose d'utile avec les informations fournies par le récepteur. Les traçeurs sont des consommateurs d'événements et de données fournies par les sources de traçage. Par exemple, on peut créer un récepteur de traçage qui (lorsqu'il est connecté à la source de traçage de l'exemple précédent) imprimera les parties d'intérêt du paquet reçu.
Un fondement raisonnable pour cette séparation explicite est de permettre aux utilisateurs de connecter de nouveaux types de récepteurs aux sources de traçage existantes sans avoir à modifier et recompiler le noyau du simulateur. Ainsi, dans l'exemple ci-dessus, l'utilisateur peut définir un nouveau traçeur dans son script et le connecter à une source de traçage existante définie dans le noyau de simulation simplement en modifiant son script utilisateur.
Dans ce guide, nous allons passer en revue certaines sources et récepteurs prédéfinis et montrer comment les configurer avec le moins d'efforts de la part de l'utilisateur. Voir le Guide ns-3 ou les sections d'instructions pour des informations sur la configuration avancée du traçage, y compris l'extension de l'espace de noms de traçage et la création de nouvelles sources de traçage.
5.3.1 ASCII Tracing
ns-3 fournit une fonctionnalité auxiliaire qui offre un système de traçage de bas niveau pour vous aider avec les détails lors de la configuration de tracés de paquets simples. Si vous activez cette fonction, vous verrez les sorties dans des fichiers ASCII. Pour ceux qui sont familiers avec la sortie de ns-2, ce type de traçage est similaire à out.tr, qui est généré par de nombreux scripts.
Passons aux choses concrètes 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 dans de nombreuses autres idiomes de ns-3, ce code utilise un objet auxiliaire pour créer des traces ASCII. La deuxième ligne contient deux appels de méthode imbriqués. La méthode 'interne' CreateFileStream() utilise l'idiome de l'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. À l'avenir, nous approfondirons ce sujet, mais tout ce que vous devez savoir à ce stade, c'est que vous créez un objet représentant un fichier nommé myfirst.tr et le transmettez à ns-3. Nous laissons à ns-3 la responsabilité de l'objet créé pendant toute sa durée de vie, au cours de laquelle les problèmes causés par la connaissance limitée (intentionnelle) des constructeurs de copie d'objets de flux C++ sont résolus.
L'appel externe EnableAsciiAll() informe l'assistant que vous souhaitez activer le traçage ASCII pour toutes les connexions à point-à-point dans votre simulation et que vous voulez que les récepteurs de traçage (indiqués) enregistrent les informations de déplacement des paquets au format ASCII.
Pour ceux qui connaissent ns-2, les événements suivis sont équivalents aux points de traçage connus qui enregistrent les événements '+', '-', 'd' et 'r'.
Vous pouvez maintenant compiler le script et l'exécuter à partir de la ligne de commande :
$ ./waf --run scratch/myfirstCombien de fois avez-vous vu des messages de Waf, puis "‘build’ finished successfully" (la construction a réussi) avec un certain nombre de messages d'un programme en cours d'exécution ?
En cours d'exécution, le programme créera un fichier nommé myfirst.tr. En raison de la manière dont fonctionne Waf, par défaut, le fichier n'est pas créé dans le répertoire local, mais dans le répertoire supérieur du dépôt. Si vous souhaitez modifier le chemin où les traces sont enregistrées, vous pouvez utiliser l'option --cwd. Comme nous ne l'avons pas fait, pour jeter un œil au fichier de trace ASCII myfirst.tr dans votre éditeur préféré, nous devrons naviguer vers le répertoire supérieur de notre dépôt.
Parsing ASCII Traces
Il y a beaucoup d'informations dans un format assez dense, mais la première chose à noter est que le fichier est composé de lignes distinctes. Cela sera assez clair si vous élargissez la fenêtre de visualisation.
Chaque ligne du fichier correspond à un événement de traçage. Dans ce cas, nous traçons des événements dans la file d'attente de transmission présente dans chaque appareil réseau point à point dans la simulation. La file d'attente de transmission est la file par laquelle chaque paquet doit passer pour le canal point à point. Notez que chaque ligne du fichier de traçage commence par un caractère unique (et a un espace après). Ce caractère aura la signification suivante :
+ : une opération d'ajout a eu lieu dans la file de l'appareil ;
- : une opération de retrait a eu lieu dans la file de l'appareil ;
d : le paquet a été abandonné, généralement parce que la file était pleine ;
r : le paquet a été reçu par l'appareil réseau.
Examinons plus en détail la première ligne du fichier de traçage. Je vais la découper en parties (avec des indentations pour la clarté) et le numéro de ligne à gauche :
0 +
1 2
2 /NodeList/0/DeviceList/0/$ns3::PointToPointNetDevice/TxQueue/Enqueue
3 ns3::PppHeader (
4 Protocole point à point : IP (0x0021))
6 ns3::Ipv4Header (
7 tos 0x0 ttl 64 id 0 protocole 17 décalage 0 drapeaux [aucun]
8 longueur : 1052 10.1.1.1 > 10.1.1.2)
9 ns3::UdpHeader (
10 longueur : 1032 49153 > 9)
11 Charge utile (taille=1024)La première partie de cet événement de traçage enrichi (ligne 0) est l'opération. Ici, nous avons le symbole +, qui correspond à une opération d'ajout à la file pour la transmission. La deuxième partie (ligne 1) est le temps de simulation, exprimé en secondes. Vous vous souviendrez peut-être que nous avons demandé. UdpEchoClientApplication Commencer l'envoi des paquets dans deux secondes. Ici, nous voyons la confirmation que cela se produit réellement.
La section suivante de l'exemple de traçage (à partir de la ligne 2) montre quel système a généré cet événement (l'espace de noms du traçage est indiqué). Vous pouvez considérer l'espace de noms de traçage de la même manière que l'espace de noms d'un système de fichiers. La racine de l'espace de noms est NodeList. Cela correspond au conteneur géré dans le code principal de ns-3. Il contient tous les nœuds qui sont créés dans le script. Tout comme un système de fichiers peut avoir des répertoires à sa racine, dans NodeList nous pouvons avoir plusieurs nœuds. Ainsi, la ligne /NodeList/0 fait référence au nœud zéro dans NodeList, que nous comprenons généralement comme « nœud 0 ». Chaque nœud possède une liste des dispositifs qui ont été installés. Cette liste se trouve ensuite dans l'espace de noms. Vous pouvez voir que cet événement de traçage provient de DeviceList/0, qui est le dispositif zéro installé dans le nœud.
La sous-chaîne suivante, $ ns3 :: PointToPointNetDevice, indique quel dispositif se trouve à la position zéro : dans la liste des dispositifs du nœud zéro. Rappelons que l'opération +, située à la ligne 0, signifiait qu'un élément a été ajouté à la file d'attente de transmission du dispositif. Cela se reflète dans les derniers segments du « chemin de traçage » : TxQueue/Enqueue.
Les autres sections du traçage devraient être assez intuitives. Les lignes 3-4 indiquent que le paquet est encapsulé dans le 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 indique que la charge utile est de 1024 octets attendus.
La ligne suivante dans le fichier de traçage indique 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 dans le fichier de traçage montre que le paquet a été reçu par le dispositif réseau sur le nœud avec le serveur écho. J'ai reproduit cet é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 longueur: 1052 10.1.1.1 > 10.1.1.2)
6 ns3::UdpHeader (
7 longueur: 1032 49153 > 9)
8 Charge utile (taille=1024)Veuillez noter que l'opération de traçage est maintenant r et que le temps de simulation a été augmenté à 2,25732 secondes. Si vous avez suivi attentivement les instructions du tutoriel, cela signifie que vous avez laissé le DataRate des appareils réseau et la latence du canal à leurs valeurs par défaut. Ce temps devrait vous sembler familier, car vous l'avez déjà vu dans la section précédente.
L'enregistrement de l'espace de noms de la source de traçage (ligne 2) a été modifié pour indiquer que cet événement provient du nœud 1 (\/NodeList/1) и пакет принят источником трассировки (/MacRx). Il devrait être assez facile de suivre le mouvement du paquet à travers la topologie en consultant les restes du fichier de traçage.
5.3.2 PCAP Tracing
Les assistants d'appareils ns-3 peuvent également être utilisés pour créer des fichiers de traçage au format .pcap. L'acronyme pcap (habituellement écrit en minuscules) désigne la capture de paquets et constitue en fait une API qui inclut la définition du format de fichier .pcap. Le programme le plus populaire qui peut lire et afficher ce format est Wireshark (anciennement appelé Ethereal). Cependant, il existe de nombreux analyseurs de traçage de trafic qui utilisent ce format de paquet. Nous recommandons aux utilisateurs d'utiliser plusieurs outils disponibles pour analyser les traçages pcap. Dans ce guide, nous nous concentrerons sur la visualisation des traçages pcap avec tcpdump.
L'activation de la traçabilité pcap se fait par une ligne de code.
pointToPoint.EnablePcapAll ("myfirst");Insérez cette ligne de code après le code de traçage ASCII que nous venons d'ajouter dans scratch/myfirst.cc. Notez que nous avons passé uniquement la chaîne « myfirst », et non « myfirst.pcap » ou quelque chose de similaire. C'est parce que le paramètre est un préfixe, et non le nom complet du fichier. Pendant la simulation, l'assistant créera en fait un fichier de traçage pour chaque appareil point à point. Les noms des fichiers seront construits à l'aide du préfixe, du numéro de nœud, du numéro d'appareil et du suffixe « .pcap».
Pour notre exemple de scénario, nous finirons par voir des fichiers nommés «myfirst-0-0.pcap» et «myfirst-1-0.pcap», qui sont des traçages pcap pour le nœud 0-appareil 0 et le nœud 1-appareil 0 respectivement. Une fois que vous avez ajouté la ligne de code pour activer la traçabilité pcap, vous pouvez exécuter le script comme d'habitude :
$ ./waf --run scratch/myfirstSi vous regardez dans le répertoire racine de votre distribution, vous devriez voir trois fichiers : le fichier de traçage ASCII myfirst.tr, que nous avons étudié précédemment, les fichiers myfirst-0-0.pcap et myfirst-1-0.pcap — nouveaux fichiers pcap que nous venons de générer.
Lecture de la sortie avec tcpdump
Actuellement, la façon la plus simple de visualiser les fichiers pcap est d'utiliser tcpdump.
$ tcpdump -nn -tt -r myfirst-0-0.pcap
lecture du fichier myfirst-0-0.pcap, type de lien PPP (PPP)
2.000000 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, longueur 1024
2.514648 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, longueur 1024
tcpdump -nn -tt -r myfirst-1-0.pcap
lecture du fichier myfirst-1-0.pcap, type de lien PPP (PPP)
2.257324 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, longueur 1024
2.257324 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, longueur 1024Dans le dump myfirst-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 (myfirst-1-0.pcap), vous verrez que le paquet est reçu à 2,257324 secondes. Vous verrez dans le deuxième dump que le paquet est retourné à 2,257324 secondes, et enfin que le paquet a été reçu par le client dans le premier dump à 2,514648 secondes.
Lecture de la sortie avec Wireshark
Si vous n'êtes pas familiarisé avec Wireshark, il existe un site web à partir duquel vous pouvez télécharger des programmes et de la documentation : . Wireshark — c'est une interface graphique que vous pouvez utiliser pour afficher ces fichiers de traçage. Si vous avez Wireshark, vous pouvez ouvrir n'importe quel fichier de traçage et visualiser son contenu comme si vous aviez capturé des paquets à l'aide d'un analyseur de paquets.
Source : habr.com
