プロホスト > ブログ > 行政 > ns-3 ネットワヌク シミュレヌタヌのチュヌトリアル。 第5ç« 

ns-3 ネットワヌク シミュレヌタヌのチュヌトリアル。 第5ç« 

ns-3 ネットワヌク シミュレヌタヌのチュヌトリアル。 第5ç« 
第1,2章
第3章
第4章

5 蚭定
5.1 ロギングモゞュヌルの䜿甚
5.1.1 ロギングの抂芁
5.1.2 ログを有効にする
5.1.3 コヌドぞのログの远加
5.2 コマンドラむン匕数の䜿甚
5.2.1 デフォルトの属性倀の䞊曞き
5.2.2 独自のコマンドのキャプチャ
5.3 トレヌスシステムの䜿甚
5.3.1 ASCII トレヌス
ASCII トレヌスの解析
5.3.2 PCAP トレヌス

ç« 5

調敎

5.1 ロギングモゞュヌルの䜿甚

スクリプトを芋お、ns-3 ロギング モゞュヌルに぀いお簡単に説明したした。 最初の.cc。 この章では、ロギング サブシステムの可胜な甚途を詳しく芋おいきたす。

5.1.1 ロギングの抂芁

倚くの倧芏暡システムは、䜕らかのメッセヌゞ ログ機胜をサポヌトしおおり、ns-3 も䟋倖ではありたせん。 堎合によっおは、゚ラヌ メッセヌゞのみが「オペレヌタ コン゜ヌル」 (通垞、Unix ベヌスのシステムでは stderr) に曞き蟌たれたす。 他のシステムでは、譊告メッセヌゞずより詳现な情報が衚瀺される堎合がありたす。 堎合によっおは、ログ ツヌルを䜿甚しおデバッグ メッセヌゞが出力されるため、出力がすぐに䞍鮮明になる可胜性がありたす。

ns-3 で䜿甚される subHRD は、これらのレベルの情報コンテンツがすべお有甚であるこずを前提ずしおおり、メッセヌゞ ログに察する遞択的で階局的なアプロヌチを提䟛したす。 ロギングは完党に無効にするこずも、コンポヌネントごずに有効にするこずも、グロヌバルに有効にするこずもできたす。 この目的のために、調敎可胜なレベルの情報コンテンツが䜿甚されたす。 ns-3 ロギング モゞュヌルは、シミュレヌションから有甚な情報を取埗する比范的簡単な方法を提䟛したす。

モデルからデヌタを抜出するための汎甚メカニズムであるトレヌスが提䟛されおいるこずを理解しおください。これは、シミュレヌションの優先出力ずなるはずです (トレヌス システムの詳现に぀いおは、チュヌトリアルのセクション 5.3 を参照しおください)。 ロギングは、デバッグ情報、譊告、゚ラヌ メッセヌゞを取埗したり、スクリプトやモデルからメッセヌゞをい぀でもすぐに出力したりする堎合に掚奚される方法です。

珟圚、システムでは、情報内容の倧きい順に XNUMX ぀のレベル (皮類) のログ メッセヌゞが定矩されおいたす。

  • LOG_ERROR - ゚ラヌ メッセヌゞのログ蚘録 (関連マクロ: NS_LOG_ERROR)。
  • LOG_WARN - ログ譊告メッセヌゞ (関連マクロ: NS_LOG_WARN)。
  • LOG_DEBUG - 比范的たれな特別なデバッグ メッセヌゞをログに蚘録したす (関連マクロ: NS_LOG_DEBUG)。
  • LOG_INFO - プログラムの進行状況に関する情報メッセヌゞの登録 (関連マクロ: NS_LOG_INFO);
  • LOG_FUNCTION - 呌び出された各関数を説明するメッセヌゞをログに蚘録したす (メンバヌ関数に䜿甚される NS_LOG_FUNCTION ず静的関数に䜿甚される NS_LOG_FUNCTION_NOARGS の XNUMX ぀の関連マクロ)。
  • LOG_LOGIC - 関数内の論理フロヌを説明するログメッセヌゞ (関連マクロ: NS_LOG_LOGIC)。
  • LOG_ALL - 䞊蚘のすべおをログに蚘録したす (関連するマクロはありたせん)。
    各タむプ (LOG_TYPE) には LOG_LEVEL_TYPE もあり、これを䜿甚するず、それ自䜓のレベルに加えお、その䞊のすべおのレベルをログに蚘録できるようになりたす。 (結果ずしお、LOG_ERROR ず LOG_LEVEL_ERROR、および LOG_ALL ず LOG_LEVEL_ALL は機胜的に同等です。) たずえば、LOG_INFO を有効にするず、NS_LOG_INFO マクロによっお提䟛されるメッセヌゞのみが蚱可されたすが、LOG_LEVEL_INFO を有効にするず、マクロ NS_LOG_DEBUG、NS_LOG_WARN、および NS_LOG_ERROR によっお提䟛されるメッセヌゞも含たれたす。

たた、ログ レベルや遞択コンポヌネントに関係なく、垞に衚瀺される無条件のログ マクロも提䟛したす。

  • NS_LOG_UNCOND - 関連メッセヌゞの無条件ロギング (関連ロギング レベルなし)。

各レベルは個別にたたは环積的にク゚リできたす。 ロギングは、sh 環境倉数 NS_LOG を䜿甚するか、システム関数呌び出しのログを蚘録するこずによっお構成できたす。 前に瀺したように、ロギング システムには Doxygen のドキュメントがあり、ただレビュヌしおいない堎合は、この機䌚にレビュヌしおください。

ドキュメントを詳しく読んだので、その知識を利甚しおサンプル スクリプトから興味深い情報を取埗したしょう。 スクラッチ/myfirst.ccすでにコンパむル枈みのものです。

5.1.2 ログを有効にする

NS_LOG 環境倉数を䜿甚しおさらにログを実行したしょう。ただし、たず、状況を把握するために、前に行ったように最埌のスクリプトを実行したす。

$ ./waf --run scratch/myfirst

最初の 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

䞊に衚瀺される「送信」メッセヌゞず「受信」メッセヌゞは、実際には次からログに蚘録されたメッセヌゞであるこずがわかりたす。 UdpEchoクラむアントアプリケヌション О UdpEchoサヌバヌアプリケヌション。 たずえば、NS_LOG 環境倉数を介しおログ レベルを蚭定するこずで、クラむアント アプリケヌションに远加情報を出力するように䟝頌できたす。

ここからは、「VARIABLE=value」構文を䜿甚する sh に䌌たシェルを䜿甚しおいるず仮定したす。 csh のようなシェルを䜿甚しおいる堎合は、私の䟋をそれらのシェルで必芁な「setenv 倉数倀」構文に倉換する必芁がありたす。

珟圚、UDP ゚コヌ クラむアント アプリケヌションは、次のコヌド行に応答したす。 スクラッチ/myfirst.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

ログレベル LOG_LEVEL_INFO を有効にしたす。 ロギング レベル フラグを枡すず、実際にはそのレベルずすべおの䞋䜍レベルが有効になりたす。 この堎合、NS_LOG_INFO、NS_LOG_DEBUG、NS_LOG_WARN、NS_LOG_ERROR を有効にしたした。 NS_LOG 環境倉数を次のように蚭定するず、スクリプトの倉曎や再コンパむルを行わずに、ログ レベルを䞊げおより倚くの情報を取埗できたす。

$ export NS_LOG=UdpEchoClientApplication=level_all

そこで、sh シェル倉数 NS_LOG を次の倀に蚭定したす。

UdpEchoClientApplication=level_all

割り圓おの巊偎は構成するログに蚘録されたコンポヌネントの名前で、右偎はそれに適甚するフラグです。 この堎合、アプリケヌションですべおのレベルのデバッグを有効にしたす。 NS_LOG をこのように蚭定しおスクリプトを実行するず、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.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()

アプリケヌションによっお提䟛される远加のデバッグ情報は、NS_LOG_FUNCTION レベルになりたした。 スクリプト実行䞭の関数呌び出しのすべおのむンスタンスが衚瀺されたす。 原則ずしお、メ゜ッド関数では (少なくずも) を䜿甚するこずが望たしいです。NS_LOG_FUNCTION (this)..。 䜿甚 NS_LOG_FUNCTION_NOARGS ()
静的関数内のみ。 ただし、ns-3 システムはログ機胜をサポヌトする必芁がないこずに泚意しおください。 蚘録される情報の量に関する決定は、個々のモデル開発者に任されおいたす。 ゚コヌ アプリケヌションの堎合、倧量のログ出力が利甚可胜です。

アプリケヌションによっお行われた関数呌び出しのログを衚瀺できるようになりたした。 よく芋るず、行の間にコロンがあるこずに気づきたす。 UdpEchoクラむアントアプリケヌション メ゜ッドの名前。ここには C++ スコヌプ挔算子 (: :) が含たれるず思われたす。 これは意図的なものです。

これは実際にはクラスの名前ではなく、ロギング コンポヌネントの名前です。 ゜ヌス ファむルずクラスが䞀臎する堎合、通垞はクラス名ですが、実際にはクラス名ではなく、二重コロンではなく単䞀コロンがあるこずに泚意しおください。 これは、比范的埮劙な方法でロギング Bean 名をクラス名から抂念的に分離するのに圹立぀方法です。

ただし、堎合によっおは、どのメ゜ッドが実際にログ メッセヌゞを生成しおいるかを刀断するこずが難しい堎合がありたす。 䞊のテキストを芋るず、「」ずいう行がどこにあるのか疑問に思うかもしれたせん。Received 1024 bytes from 10.1.1.2」 レベルを蚭定するこずでこの問題を解決できたす プレフィックス_機胜 NS_LOG 環境倉数に远加したす。 次のこずを詊しおください。

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

OR 挔算を衚すために䜿甚する瞊棒も Unix パむプ コネクタであるため、匕甚笊が必芁であるこずに泚意しおください。 ここでスクリプトを実行するず、ログ システムによっお、特定のログ内のすべおのメッセヌゞにコンポヌネント名が接頭蟞ずしお付けられるこずがわかりたす。

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()

これで、UDP ゚コヌ クラむアント アプリケヌションからのすべおのメッセヌゞがそのように識別されたこずがわかりたす。 メッセヌゞ "Received 1024 bytes from 10.1.1.2" は、echo クラむアント アプリケヌションからのものであるこずが明確に識別されるようになりたした。 残りのメッセヌゞは UDP ゚コヌ サヌバヌ アプリケヌションから送信される必芁がありたす。 このコンポヌネントを有効にするには、コロンで区切られたコンポヌネントのリストを NS_LOG 環境倉数に入力したす。

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

è­Šå‘Š: 䞊蚘のテキスト䟋では、コロン (:) の埌の改行文字を削陀する必芁がありたす。改行文字はドキュメントの曞匏蚭定に䜿甚されたす。 ここでスクリプトを実行するず、クラむアントずサヌバヌの゚コヌ アプリケヌションからのすべおのログ メッセヌゞが衚瀺されたす。 これはデバッグ時に非垞に䟿利であるこずがわかりたす。

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()

ログ メッセヌゞが生成されたシミュレヌション時間を確認できるず䟿利な堎合もありたす。 ORビットを远加するこずでこれを行うこずができたす プレフィックス時間:

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

ここでも、䞊蚘の改行文字を削陀する必芁がありたす。 ここでスクリプトを実行するず、次の出力が衚瀺されるはずです。

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()

コンストラクタヌは次のこずに泚意しおください。 UdpEchoサヌバヌ シミュレヌション䞭に 0 秒間呌び出されたした。 これは実際にはシミュレヌションの開始前に発生したすが、時間は XNUMX 秒ずしお衚瀺されたす。 コンストラクタヌメッセヌゞにも同じこずが圓おはたりたす UdpEchoクラむアント.

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()

スクリプトを思い出しおください スクラッチ/first.cc シミュレヌション開始の XNUMX 秒前に゚コヌ サヌバヌ アプリケヌションを開始したした。 これで、メ゜ッドが アプリケヌションの開始 サヌバヌは実際には最初の XNUMX 秒で呌び出されたす。 スクリプトで芁求したように、゚コヌ クラむアントがシミュレヌションの XNUMX 秒目に開始されるこずにも気づくでしょう。

通話䞭にシミュレヌションの進行状況を远跡できるようになりたした スケゞュヌル送信 HandleRead コヌルバックを呌び出すクラむアント内 ゚コヌ サヌバヌ アプリケヌションで送信したす。 ポむントツヌポむント リンク経由でパケットを送信するのにかかる時間は 3,69 ミリ秒であるこずに泚意しおください。 ゚コヌ サヌバヌがパケットに応答したこずを瀺すメッセヌゞをログに蚘録し、チャネル遅延の埌、゚コヌ クラむアントが HandleRead メ゜ッドで゚コヌ パケットを受信しお​​いるこずがわかりたす。

このシミュレヌションでは、気づかないうちに倚くのこずが起こりたす。 ただし、システム内のすべおのログ コンポヌネントを有効にするこずで、プロセス党䜓を非垞に簡単に远跡できたす。 NS_LOG 倉数を次の倀に蚭定しおみおください。

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

䞊のアスタリスクは、ログ コンポヌネントのワむルドカヌド文字です。 これには、シミュレヌションで䜿甚されるすべおのコンポヌネントのすべおの゚ントリが含たれたす。 ここでは出力を再珟したせん (この蚘事の執筆時点では、1265 ぀の゚コヌ パケットに察しお XNUMX 行の出力が生成されたす) が、この情報をファむルにリダむレクトしお、奜みの゚ディタヌで衚瀺するこずができたす。

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

私は個人的に、問題があり、どこで問題が起こったのかわからないずきに、この非垞に詳现なバヌゞョンのロギングを䜿甚しおいたす。 ブレヌクポむントを蚭定したり、デバッガヌでコヌドをステップ実行したりするこずなく、コヌドの実行を非垞に簡単に远跡できたす。 お気に入りの゚ディタヌで出力を線集し、期埅どおりの結果を探しおみるず、予想倖のこずが起こるこずがわかりたす。 䜕が問題なのかを倧たかに把握したら、デバッガヌを起動しお問題を掘り䞋げたす。 このタむプの出力は、スクリプトがたったく予期しない動䜜をする堎合に特に圹立ちたす。 デバッガヌのみを䜿甚しおいる堎合は、ひねりを完党に芋逃しおしたう可胜性がありたす。 登録するず、そのような倉化が顕著になりたす。

5.1.3 コヌドぞのログの远加

耇数のマクロからログ コンポヌネントを呌び出すこずで、シミュレヌションに新しい゚ントリを远加できたす。 スクリプトでやっおみよう myfirst.ccこれは「clean」ディレクトリにありたす。 このシナリオでログ コンポヌネントを定矩したこずを思い出しおください。

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

NS_LOG 環境倉数をさたざたなレベルで蚭定するず、このコンポヌネントからのすべおのメッセヌゞのログを有効にできるこずがわかりたした。 スクリプトにいく぀かの゚ントリを远加しおみたしょう。 情報レベルのメッセヌゞをログに远加するために䜿甚されるマクロは NS_LOG_INFO です。 スクリプトが「トポロゞの䜜成」フェヌズにあるこずを通知するメッセヌゞを (ノヌドの䜜成を開始する盎前に) 远加したしょう。 これは次のコヌド スニペットで行われたす。
開く スクラッチ/myfirst.cc お気に入りの゚ディタヌで次の行を远加したす。
NS_LOG_INFO ("Creating Topology");
行の盎前に、

NodeContainer nodes;
nodes.Create (2);

次に、次を䜿甚しおスクリプトをコンパむルしたす。 WAF、 NS_LOG 倉数をクリアしお、前に有効にしたログ ストリヌムを無効にしたす。

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

関連するログ コンポヌネント (FirstScriptExample) が有効になっおいないため、新しいメッセヌゞは衚瀺されたせん。 メッセヌゞを衚瀺するには、ログコンポヌネントを有効にする必芁がありたす 最初のスクリプトの䟋 NS_LOG_INFO 以䞊のレベル。 この特定のログレベルを確認したいだけの堎合は、次のように有効にできたす。

$ export NS_LOG=FirstScriptExample=info

ここでスクリプトを実行するず、「トポロゞの䜜成」ずいう新しいメッセヌゞが衚瀺されたす。

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 コマンドラむン匕数の䜿甚

5.2.1 デフォルトの属性倀の䞊曞き

線集やビルドを行わずに ns-3 スクリプトの動䜜を倉曎するもう XNUMX ぀の方法は、コマンド ラむン匕数を䜿甚するこずです。 コマンドラむン匕数を解析し、その結果に基づいおロヌカル倉数ずグロヌバル倉数を自動的に蚭定するメカニズムを提䟛したす。

コマンド ラむン匕数システムを䜿甚する最初の手順は、コマンド ラむン パヌサヌを宣蚀するこずです。 次のコヌドのように、これは (メむン プログラム内で) 非垞に簡単に実行できたす。

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

この単玔な 3 行のスニペットは、実際にはそれ自䜓で非垞に䟿利です。 これは、ns-XNUMX グロヌバル倉数および属性システムぞの扉を開きたす。 メむン スクリプト関数の先頭に XNUMX 行のコヌドを远加したしょう。 スクラッチ/myfirst.cc。 次に、スクリプトをコンパむルしお実行したす。実行時に次のようにヘルプ リク゚ストを䜜成したす。

$ ./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.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.

それではオプションを芋おみたしょう —PrintAttributes。 first.cc スクリプトを怜蚎したずきに、ns-3 属性システムに぀いおはすでに述べたした。 次のコヌド行を確認したした。

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

そしお圌らはこう蚀いたした デヌタレヌト 実際には属性です ポむントツヌポむントネットデバむス。 コマンドラむン匕数パヌサヌを䜿甚しお属性を衚瀺したしょう ポむントツヌポむントネットデバむス。 ヘルプ リストには、提䟛する必芁があるものが蚘茉されおいたす タむプID。 これは、察象の属性が属するクラスの名前です。 私たちの堎合は次のようになりたす ns3::PointToPointNetDevice。 前に進もう、入っお、

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

システムは、このネットワヌク デバむス タむプのすべおの属性を出力したす。 リスト内の属性には次のものがあるこずがわかりたす。

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

これは、オブゞェクトの䜜成時にシステムによっお䜿甚されるデフォルト倀です。 ポむントツヌポむントネットデバむス。 パラメヌタを䜿甚しおこのデフォルト倀をオヌバヌラむドしたす。 属性 в ポむントツヌポむントヘルパヌ より高い。 ポむントツヌポむント デバむスずチャネルにはデフォルト倀を䜿甚したしょう。 これを行うには、通話を削陀したす デバむス属性の蚭定 О SetChannelAttribute の myfirst.cc、これはクリヌンなディレクトリにありたす。

スクリプトは次のように宣蚀するだけです。 ポむントツヌポむントヘルパヌ たた、以䞋の䟋に瀺すようなむンストヌル操䜜は実行しないでください。

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

新しいスクリプトを䜜成しおください ワフ (./waff) に戻っお、UDP ゚コヌ サヌバヌ アプリケヌションからの゚ントリを含めお、時刻プレフィックスを含めおみたしょう。

$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'

スクリプトを実行するず、次の出力が衚瀺されるはずです。

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()

最埌にシミュレヌション時間を調べたずき、぀たり゚コヌ サヌバヌがパケットを受信した瞬間の時間が 2,00369 秒だったこずを思い出しおください。

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

珟圚、圌は 2.25732 秒以内にパケットを受信したす。 これは、PointToPointNetDevice デヌタ レヌトを 32768 メガビット/秒からデフォルト倀の XNUMX ビット/秒にリセットしただけであるためです。 コマンド ラむンを䜿甚しお新しい DataRate を眮き換えるず、シミュレヌションを再び高速化できたす。 help 芁玠によっお暗瀺される匏に埓っお、これを次のように実行したす。

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

これにより、DataRate 属性がデフォルト倀の XNUMX メガビット/秒に戻りたす。 その結果に驚きたしたか? スクリプトの元の動䜜に戻すには、光の速床に䞀臎するようにチャネル遅延を蚭定する必芁があるこずがわかりたした。 ネットワヌク デバむスの堎合ず同じように、コマンド ラむン システムにチャネル属性を出力するように䟝頌できたす。

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

チャネル遅延属性が次のように蚭定されおいるこずがわかりたす。

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

次に、コマンド ラむン システムを䜿甚しお、これらの䞡方のデフォルト倀を蚭定できたす。

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

この堎合、スクリプトで DataRate ず Delay を明瀺的に蚭定したずきの時間を埩元したす。

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()

パケットは 2,00369 秒埌にサヌバヌによっお再床受信されるこずに泚意しおください。 実際には、スクリプトで䜿甚される任意の属性をこの方法で蚭定できたす。 特に、MaxPackets 属性を XNUMX 以倖の倀に蚭定できたす。 UdpEchoクラむアント.

どのように䜿甚したすか? 詊しおみる。 デフォルトの属性倀をオヌバヌラむドしお明瀺的に蚭定する堎所をコメントアりトする必芁があるこずに泚意しおください。 最倧パケット数 スクリプトで。 次に、スクリプトを再構築する必芁がありたす。 コマンド ラむンを䜿甚しお、新しいデフォルト属性倀を蚭定するための構文ヘルプを取埗するこずもできたす。 これを理解するず、コマンド ラむンに衚瀺されるパッケヌゞの数を制埡できるようになりたす。 私たちは勉匷家なので、コマンドラむンは次のようになりたす。

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

この時点で生じる圓然の疑問は、これらすべおの属性の存圚をどのようにしお知るかずいうこずです。 繰り返したすが、コマンド ラむン システムには、この問題に関するヘルプ機胜がありたす。 コマンドラむンにヘルプを求めるず、以䞋が衚瀺されるはずです。

$ ./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.

「PrintGroups」匕数を遞択するず、登録されおいるすべおのグルヌプのリストが衚瀺されたす。 タむプID。 グルヌプ名は、゜ヌス ディレクトリ内のモゞュヌルの名前ず䞀臎しおいたす (倧文字ですが)。 すべおの情報を䞀床に印刷するず膚倧になるため、远加のフィルタヌを䜿甚しお情報をグルヌプごずに印刷できたす。 そこで、再びポむントツヌポむント モゞュヌルに焊点を圓おたす。

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

ここでは、属性怜玢に䜿甚できる TypeId 名を芋぀けるこずができたす。たずえば、
--PrintAttributes = ns3 :: PointToPointChannel䞊に瀺すように。

属性に぀いお孊ぶもう 3 ぀の方法は、Doxygen ns‑XNUMX を䜿甚するこずです。 シミュレヌタヌに登録されおいるすべおの属性をリストするペヌゞがありたす。

5.2.2 独自のコマンドのキャプチャ

コマンドラむン システムを䜿甚しお独自のフックを远加するこずもできたす。 これは、コマンド ラむン パヌサヌ メ゜ッドを䜿甚しお非垞に簡単に実行できたす。 付加䟡倀.
この機胜を䜿甚しお、たったく異なる方法で衚瀺するパッケヌゞの数を指定しおみたしょう。 ずいうロヌカル倉数を远加したしょう nパケット 関数に メむン。 以前のデフォルトの動䜜ず䞀臎するように、これを XNUMX に蚭定したす。 コマンド ラむン パヌサヌがこの倀を倉曎できるようにするには、パヌサヌでこの倀をキャプチャする必芁がありたす。 これを行うには、呌び出しを远加したす 付加䟡倀。 行っおスクリプトを倉曎しおください スクラッチ/myfirst.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);
...

スクリプト内で MaxPackets 属性を蚭定する䜍眮たで䞋にスクロヌルし、次に瀺すように、定数 1 ではなく nPackets 倉数に蚭定されるように属性を倉曎したす。

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

ここで、スクリプトを実行しお -PrintHelp 匕数を指定するず、新しいナヌザヌ匕数が衚瀺されるはずです。 ヘルプ画面に蚘茉されおいたす。 入力、

$ ./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

送信されるパケットの数を倉曎したい堎合は、コマンド ラむン匕数 -nPackets を蚭定するこずで倉曎できたす。

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

今、あなたは今芋るはずです

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()

これで XNUMX ぀の荷物が送信されたした。 ずおもシンプルですね。
ns-3 ナヌザヌは、コマンド ラむン匕数システムを䜿甚しおグロヌバル倀ず属性を操䜜できるこずがわかりたす。 モデル䜜成者の堎合は、オブゞェクトに新しい属性を远加できたす。これらの属性は、ナヌザヌがコマンド ラむン システムを通じお自動的に構成できるようになりたす。 スクリプト䜜成者の堎合は、スクリプトに新しい倉数を远加し、それらをコマンド ラむン システムにシヌムレスに接続できたす。

5.3 トレヌスシステムの䜿甚

モデリングの芁点は、さらなる研究のための出力を生成するこずであり、ns-3 トレヌス システムはそのための䞻芁なメカニズムです。 ns-3 は C++ プログラムであるため、C++ プログラムから出力を生成する暙準的な手段を䜿甚できたす。

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

ロギング モゞュヌルを䜿甚しお、゜リュヌションに小さな構造を远加するこずもできたす。 このアプロヌチによっお匕き起こされる既知の問題が倚数あるため、これらの問題を解決するための䞀般的なむベント トレヌス サブシステムを提䟛したした。

ns-3 トレヌス システムの䞻な目的は次のずおりです。

  • 基本的なタスクの堎合、トレヌス システムでは、ナヌザヌが䞀般的な゜ヌスの暙準トレヌスを生成し、トレヌスを生成するオブゞェクトを遞択できるようにする必芁がありたす。

  • 䞭玚ナヌザヌは、シミュレヌタ コアを倉曎せずに、トレヌス システムを拡匵しお、生成された出力圢匏を倉曎したり、新しいトレヌス ゜ヌスを挿入したりできる必芁がありたす。

  • 䞊玚ナヌザヌは、シミュレヌタ コアを倉曎しお、新しいトレヌス ゜ヌスずシンクを远加できたす。 ns-3 トレヌス システムは、独立した远跡゜ヌスず受信機の原理、および゜ヌスを消費者に接続するための統䞀メカニズムに基づいお構築されおいたす。

ns-3 トレヌス システムは、独立したトレヌス ゜ヌスずレシヌバヌの原理、および゜ヌスずレシヌバヌを接続するための統合メカニズムに基づいお構築されおいたす。 トレヌス ゜ヌスは、シミュレヌション内で発生するむベントを通知し、基瀎ずなる察象デヌタぞのアクセスを提䟛できるオブゞェクトです。 たずえば、トレヌス ゜ヌスは、ネットワヌク デバむスがい぀パケットを受信したかを瀺し、関心のあるトレヌス受信者がパケットの内容を利甚できるようにするこずができたす。

トレヌス ゜ヌスは、シンクによっお提䟛される情報を䜿甚しお実際に有甚な凊理を行うコヌドの他の郚分ず「結合」しない限り、それ自䜓では圹に立ちたせん。 トレヌサは、トレヌス ゜ヌスによっお提䟛されるむベントずデヌタのコンシュヌマです。 たずえば、(前の䟋のトレヌス ゜ヌスに接続されおいる堎合に) 受信したパケット内の察象郚分を出力するトレヌス シンクを䜜成できたす。

この明瀺的な分離の根拠は、ナヌザヌがシミュレヌタヌ コアを線集しお再コンパむルするこずなく、新しいシンク タむプを既存のトレヌス ゜ヌスに接続できるようにするこずです。 したがっお、䞊蚘の䟋では、ナヌザヌはスクリプトを線集するだけで、スクリプトで新しいトレヌサヌを定矩し、シミュレヌション コアで定矩されおいる既存のトレヌス ゜ヌスに接続できたす。

このチュヌトリアルでは、いく぀かの事前定矩された゜ヌスずシンクを確認し、ナヌザヌ偎で最小限の劎力でそれらを構成する方法を瀺したす。 トレヌス名前空間の拡匵や新しいトレヌス ゜ヌスの䜜成など、高床なトレヌス蚭定の詳现に぀いおは、ns-3 マニュアルたたはハりツヌ セクションを参照しおください。

5.3.1 ASCII トレヌス

ns-3 は、単玔なパケット トレヌスを蚭定する際の詳现を支揎する䜎レベルのトレヌス システムを提䟛するヘルパヌ機胜を提䟛したす。 この機胜を有効にするず、出力が ASCII ファむルで衚瀺されたす。 ns-2 出力に慣れおいる人にずっお、このタむプのトレヌスは次のようになりたす。 アりト.tr、倚くのスクリプトによっお生成されたす。

本題に取り掛かり、ASCII トレヌス結果をScratch/myfirst.cc スクリプトに远加したしょう。 電話をかける盎前に Simulator :: Run ()に、次のコヌド行を远加したす。
AsciiTraceHelper ascii;

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

他の倚くの ns-3 むディオムず同様に、このコヌドはヘルパヌ オブゞェクトを䜿甚しお ASCII トレヌスを䜜成したす。 XNUMX 行目には XNUMX ぀のネストされたメ゜ッド呌び出しが含たれおいたす。 「内偎」メ゜ッド CreateFileStream() 匿名オブゞェクト むディオムを䜿甚しおスタック䞊にファむル ストリヌム オブゞェクト (オブゞェクト名なし) を䜜成し、それを呌び出されたメ゜ッドに枡したす。 これに぀いおは今埌さらに詳しく説明したすが、この時点で知っおおく必芁があるのは、次のファむルを衚すオブゞェクトを䜜成しおいるずいうこずだけです。 myfirst.tr それをns-3に転送したす。 䜜成されたオブゞェクトをその存続期間党䜓にわたっお管理するこずを ns-3 に委蚗し、その間、C++ ストリヌム オブゞェクト コピヌ コンストラクタヌに関連するあたり知られおいない (意図的な) 制限によっお匕き起こされる問題を解決したす。

倖線通話 EnableAsciiAll() すべおのポむントツヌポむント デバむス接続のシミュレヌションに ASCII トレヌスを含めるこず、および (指定された) トレヌス レシヌバヌがパケット移動情報を ASCII 圢匏で蚘録するこずをアシスタントに指瀺したす。

ns-2 に詳しい人にずっお、远跡されるむベントは、むベント「+」、「-」、「d」、および「r」を蚘録する既知のトレヌスポむントず同等です。
これで、スクリプトをビルドしおコマンド ラむンから実行できるようになりたす。

$ ./waf --run scratch/myfirst

これたで䜕床もあったように、Waf からのいく぀かのメッセヌゞが衚瀺され、その埌、実行䞭のプログラムからのいく぀かのメッセヌゞずずもに「'ビルド' が正垞に終了したした」ずいうメッセヌゞが衚瀺されたす。

実行するず、プログラムは次の名前のファむルを䜜成したす。 myfirst.tr。 仕事の性質䞊 ワフ、デフォルトでは、ファむルはロヌカル ディレクトリではなく、リポゞトリの最䞊䜍ディレクトリに䜜成されたす。 トレヌスが保存されるパスを倉曎したい堎合は、Waf パラメヌタを䜿甚しお指定できたす。 --cwd。 これはただ行っおいないため、お気に入りの゚ディタヌで ASCII トレヌス ファむル myfirst.tr を確認するには、リポゞトリの最䞊䜍ディレクトリに移動する必芁がありたす。

ASCII トレヌスの解析

そこにはかなり高密床の圢匏で倚くの情報が含たれおいたすが、最初に泚目する必芁があるのは、ファむルが個々の行で構成されおいるずいうこずです。 衚瀺りィンドりをさらに拡倧するず、これがはっきりず衚瀺されたす。

ファむル内の各行はトレヌス むベントに察応したす。 この堎合、シミュレヌション内の各ポむントツヌポむント ネットワヌク デバむスに存圚する送信キュヌ内のむベントを远跡したす。 送信キュヌは、ポむントツヌポむント リンクで各パケットが通過する必芁があるキュヌです。 トレヌス ファむルの各行は XNUMX 文字で始たる (その埌にスペヌスがある) こずに泚意しおください。 この蚘号は次の意味を持ちたす。

+: デバむスキュヌ䞊でキュヌむング操䜜が発生したした。
-: デバむスキュヌ内で芁玠の取埗操䜜が発生したした。
d: パケットはドロップされたした。通垞はキュヌがいっぱいだったためです。
r: パケットはネットワヌクデバむスによっお受信されたした。

トレヌス ファむルの最初の行を詳しく芋おみたしょう。 これをいく぀かの郚分に分割し (わかりやすくするためにむンデントを付けおいたす)、巊偎に行番号を瀺したす。

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)

この拡匵トレヌス むベントの最初のセクション (行 0) は操䜜です。 ここには + 蚘号がありたすが、これは送信のキュヌむングの操䜜に察応したす。 1 番目のセクション (XNUMX 行目) はシミュレヌション時間であり、秒単䜍で衚されたす。 私たちが尋ねたこずを芚えおいるかもしれたせん UdpEchoクラむアントアプリケヌション XNUMX 秒埌にパケットの送信を開始したす。 ここで、これが実際に起こっおいるこずが確認できたす。

トレヌス䟋の次のセクション (2 行目から) は、どのトレヌス ゜ヌスがこのむベントを生成したかを瀺したす (名前空間トレヌスを瀺したす)。 トレヌス名前空間は、ファむルシステムの名前空間ず同じように考えるこずができたす。 名前空間のルヌトは ノヌドリスト。 これは、メむンの ns-3 コヌドで管理されるコンテナヌに察応したす。 これには、スクリプトで䜜成されたすべおのノヌドが含たれたす。 ファむル システムがルヌトにディレクトリを持぀こずができるのず同じように、 ノヌドリスト 倚くのノヌドを持぀こずができたす。 したがっお、行 /NodeList/0 は、NodeList 内の null ノヌドを参照しおおり、通垞は「ノヌド 0」ず考えられたす。 各ノヌドには、むンストヌルされおいるデバむスのリストがありたす。 このリストは、名前空間の次の堎所にありたす。 このトレヌス むベントが由来しおいるこずがわかりたす。 デバむスリスト/0、これはノヌドにむンストヌルされおいるヌルデバむスです。

次の郚分文字列、 $ ns3 :: PointToPointNetDeviceは、どのデバむスが䜍眮 0 にあるかを瀺したす (ノヌド XNUMX のデバむス リスト)。 行 XNUMX で芋぀かった + 操䜜は、芁玠がデバむスの送信キュヌに远加されたこずを意味しおいたこずを思い出しおください。 これは、「トラック パス」の最埌のセグメントに反映されおいたす。 TxQueue/゚ンキュヌ.

トレヌスの残りのセクションはかなり盎感的に理解できるはずです。 行 3  4 は、パケットがポむントツヌポむント プロトコルでカプセル化されおいるこずを瀺しおいたす。 行 5  7 は、パケットに IP4 バヌゞョンのヘッダヌがあり、IP アドレスから発信されたこずを瀺しおいたす。 10.1.1.1 を察象ずしおいたす 10.1.1.2。 行 8  9 は、このパケットに UDP ヘッダヌがあるこずを瀺し、最埌に行 10 はペむロヌドが予期された 1024 バむトであるこずを瀺しおいたす。

トレヌス ファむルの次の行は、同じパケットが同じノヌド䞊の送信キュヌからプルされたこずを瀺しおいたす。

トレヌス ファむルの XNUMX 行目は、パケットが゚コヌ サヌバヌ ホスト䞊のネットワヌク デバむスによっお受信されたこずを瀺しおいたす。 以䞋にむベントを再珟したした。

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)

トレヌス操䜜が r になり、シミュレヌション時間が 2,25732 秒に増加したこずに泚意しおください。 チュヌトリアルに泚意深く埓った堎合、これはネットワヌク デバむスの DataRate ず Link Delay をデフォルト倀のたたにしたこずを意味したす。 前のセクションで芋たように、この時制には銎染みがあるはずです。

トレヌス ゜ヌス名前空間゚ントリ (行 2) は、このむベントがノヌド 1 から発生したものであるこずを反映するように倉曎されたした (/ノヌドリスト/1)、パケットはトレヌス ゜ヌス (/マック゚ックス。 ファむル内に残っおいるトレヌスを確認するこずで、トポロゞ内でのパケットの動きを远跡するのは非垞に簡単です。

5.3.2 PCAP トレヌス

ns-3 デバむス ヘルパヌを䜿甚しお、.pcap 圢匏のトレヌス ファむルを䜜成するこずもできたす。 頭字語 pcap (通垞は小文字で曞かれたす) はパケット キャプチャを衚し、実際には .pcap ファむル圢匏の定矩を含む API です。 この圢匏を読み取っお衚瀺できる最も䞀般的なプログラムは次のずおりです。 Wiresharkの (以前はこう呌ばれおいたした) ゚テル゚ル。 ただし、このパケット圢匏を䜿甚するトラフィック トレヌス アナラむザヌが倚数ありたす。 pcap トレヌスを分析するために利甚可胜な倚くのツヌルを䜿甚するこずをお勧めしたす。 このチュヌトリアルでは、次を䜿甚しお pcap トレヌスを衚瀺するこずに焊点を圓おたす。 tcpdump.

pcap トレヌスの有効化は XNUMX 行のコヌドで実行できたす。

pointToPoint.EnablePcapAll ("myfirst");

このコヌド行を、先ほど远加した ASCII トレヌス コヌドの埌に​​貌り付けたす。 スクラッチ/myfirst.cc。 「myfirst.pcap」などの文字列ではなく、文字列「myfirst」のみを枡したこずに泚意しおください。 これは、パラメヌタが完党なファむル名ではなくプレフィックスであるためです。 シミュレヌション䞭に、アシスタントは実際に各ポむントツヌポむント デバむスのトレヌス ファむルを䜜成したす。 ファむル名は、プレフィックス、ノヌド番号、デバむス番号、およびサフィックス「」を䜿甚しお構築されたす。pcap'。

このサンプル スクリプトでは、最終的に「」ずいう名前のファむルが衚瀺されたす。myfirst-0-0.pcap"そしお"myfirst-1-0.pcapこれは、それぞれノヌド 0-デバむス 0 およびノヌ​​ド 1-デバむス 0 の pcap トレヌスです。 pcap トレヌスを有効にするコヌド行を远加したら、通垞の方法でスクリプトを実行できたす。

$ ./waf --run scratch/myfirst

ディストリビュヌションの最䞊䜍ディレクトリを芋るず、次の XNUMX ぀のファむルが衚瀺されるはずです。 ASCII トレヌス ファむル myfirst.tr、以前に調査したファむル myfirst-0-0.pcap О myfirst-1-0.pcap - 生成したばかりの新しい pcap ファむル。

tcpdump による出力の読み取り

珟時点では、pcap ファむルを衚瀺する最も簡単な方法は 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

ダンプの䞭 myfirst-0-0.pcap (クラむアント デバむス) シミュレヌションの 2 秒埌に゚コヌ パケットが送信されおいるこずがわかりたす。 XNUMX 番目のダンプを芋るず (myfirst-1-0.pcap)、パケットが 2,257324 秒で受信されたこずがわかりたす。 2.257324 番目のダンプでは、パケットが 2.514648 秒で返され、最埌に、最初のダンプで XNUMX 秒でパケットがクラむアントによっお受信されたこずがわかりたす。

Wireshark による出力の読み取り

よく知らない堎合は、 Wiresharkの、プログラムずドキュメントをダりンロヌドできる Web サむトがありたす。 http://www.wireshark.org/. Wiresharkの は、これらのトレヌス ファむルを衚瀺するために䜿甚できる GUI です。 Wireshark をお持ちの堎合は、任意のトレヌス ファむルを開いお、パケット スニファを䜿甚しおパケットをキャプチャしたかのように内容を衚瀺できたす。

出所 habr.com

コメントを远加したす