ns-3 ネットワーク シミュレーターのチュートリアル。 第4章

第1,2章
第3章

4 コンセプト概要
4.1 主要な抽象化
4.1.1 ノード
4.1.2 アプリケーション
4.1.3 チャネル
4.1.4 ネットデバイス
4.1.5 トポロジカルアシスタント
4.2 最初の ns-3 スクリプト
4.2.1 定型コード
4.2.2 プラグイン
4.2.3 ns3 名前空間
4.2.4 ロギング
4.2.5 メイン機能
4.2.6 トポロジー・アシスタントの使用
4.2.7 アプリケーションの使用
4.2.8 シミュレータ
4.2.9 スクリプトの構築
4.3 ns-3 ソースコード

章4

コンセプトの概要

ns-3 コードの学習または作成を開始する前に最初に行う必要があるのは、システム内のいくつかの基本概念と抽象化を説明することです。 その多くは当然のことのように思えるかもしれませんが、しっかりとした基礎を固めるために、時間をかけてこのセクションを読むことをお勧めします。

4.1 主要な抽象化

このセクションでは、Web 上で一般的に使用されているが、ns-3 では特定の意味を持ついくつかの用語を見ていきます。

4.1.1 ノード

インターネットの専門用語では、ネットワークに接続するコンピュータ デバイスをホスト、またはエンド システムと呼ぶこともあります。 ns-3 はネットワーク シミュレータであり、インターネット シミュレータではないため、ホストという用語はインターネットとそのプロトコルに密接に関連しているため、意図的に使用しません。 代わりに、グラフ理論に由来する、他のシミュレーターでも使用される、より一般的な用語であるノード ( ).

ns-3 では、コンピューティング デバイスの基礎となる抽象化をノードと呼びます。 この抽象化は、C++ では Node クラスによって表されます。 クラス ノードノード (ノード) は、シミュレーションでコンピューティング デバイスの表現を操作するためのメソッドを提供します。

理解しなければならない Node 機能を追加するコンピューターのようなものです。 アプリケーション、プロトコル スタック、ドライバーを備えた周辺カードなどを追加して、コンピューターが有用な作業を実行できるようにします。 ns-3でも基本モデルは同じものを使用しています。

4.1.2 アプリケーション

一般に、コンピュータ ソフトウェアは大きく XNUMX つのクラスに分類されます。 システム ソフトウェアは、メモリ、プロセッサ サイクル、ディスク、ネットワークなどのさまざまなコンピュータ リソースを、何らかのコンピューティング モデルに従って編成します。 システム ソフトウェアは通常、ユーザーに直接利益をもたらすタスクを実行するためにこれらのリソースを使用しません。 通常、ユーザーは特定の目標を達成するためにアプリケーションを実行し、システム ソフトウェアによって制御されるリソースを取得して使用します。

多くの場合、システム ソフトウェアとアプリケーション ソフトウェアの間の境界線は、オペレーティング システムのトラップで発生する特権レベルの変更で引かれます。 ns-3 にはオペレーティング システムという実際の概念がないため、特権レベルやシステム コールという概念もありません。 ただし、私たちにはアプリのアイデアがあります。 「現実世界」のソフトウェア アプリケーションがコンピューター上で実行されてタスクを実行するのと同じように、ns-3 アプリケーションは ns-3 ノード上で実行され、シミュレートされた世界でシミュレーションを制御します。

ns-3 では、モデリング用のアクティビティを生成するユーザー プログラムの基本的な抽象化はアプリケーションです。 この抽象化は、C++ では Application クラスによって表されます。 Application クラスは、シミュレーションでアプリケーションのユーザーレベル バージョンのビューを操作するためのメソッドを提供します。 開発者は、新しいアプリケーションを作成するために、オブジェクト指向プログラミングの意味で Application クラスを特殊化することが期待されます。 このチュートリアルでは、Application クラスの特殊化を使用します。 UdpEchoクライアントアプリケーション и UdpEchoサーバーアプリケーション。 ご想像のとおり、これらのアプリケーションは、ネットワーク パケットの生成とエコーに使用されるクライアント/サーバー アプリケーションのセットを構成します。

4.1.3 チャネル

現実の世界では、コンピュータをネットワークに接続できます。 多くの場合、これらのネットワークでデータが送信されるメディアはチャネルと呼ばれます。 イーサネット ケーブルを壁のコンセントに差し込むと、コンピュータがイーサネット リンクに接続されます。 シミュレートされた ns-3 ワールドでは、ノードは通信チャネルを表すオブジェクトに接続されます。 ここで、通信サブネットワークの基本的な抽象化はチャネルと呼ばれ、C++ では Channel クラスによって表されます。

クラス チャンネルチャンネル は、サブネット オブジェクトの相互作用を管理し、ノードをサブネット オブジェクトに接続するためのメソッドを提供します。 開発者は、オブジェクト指向プログラミングの意味でチャネルを特殊化することもできます。 チャネルの特化により、ワイヤーのような単純なものをモデル化できます。 専用チャネルは、大型のイーサネット スイッチや、ワイヤレス ネットワークの場合は障害物でいっぱいの XNUMX 次元空間などの複雑なものをモデル化することもできます。

このチュートリアルでは、と呼ばれる特殊なバージョンのチャネルを使用します。 CsmaChannelCsmaChannel, ポイントツーポイントチャンネルポイントツーポイントチャンネル и WifiチャンネルWifiチャンネル. CsmaChannelたとえば、キャリアセンス多元接続通信環境を実装する通信サブネットのバージョンをモデル化します。 これにより、イーサネットのような機能が得られます。

4.1.4 ネットデバイス

以前は、コンピュータをネットワークに接続するには、特定のネットワーク ケーブルと、(PC 用語で) 周辺機器カードと呼ばれるハードウェア デバイスを購入し、コンピュータに取り付ける必要がありました。 周辺カードが何らかのネットワーク機能を実装している場合、それらはネットワーク インターフェイス カードまたはネットワーク カードと呼ばれます。 現在、ほとんどのコンピュータには統合ネットワーク インターフェイス ハードウェアが搭載されており、ユーザーには別個のデバイスとして認識されません。

ネットワーク カードは、ハードウェアを制御するソフトウェア ドライバーがなければ機能しません。 Unix (または Linux) では、周辺機器はデバイスとして分類されます。 デバイスはデバイス ドライバーを使用して管理され、ネットワーク デバイス (NIC) はネットワーク デバイス ドライバーを使用して管理されます (ネットワークデバイスドライバー) を総称してネットワーク デバイス (ネットデバイス）。 Unix および Linux では、ネットワーク デバイスを次のような名前で参照します。 eth0.

ns-3 では、ネットワーク デバイスの抽象化は、ソフトウェア ドライバーとモデル化されるハードウェアの両方をカバーします。 シミュレーションでは、ネットワーク デバイスがノードに「インストール」され、チャネルを通じて他のノードと通信できるようになります。 実際のコンピュータと同様に、ノードは複数のデバイスを介して複数のチャネルに接続できます。 ネットデバイス.

デバイスのネットワーク抽象化は、C++ ではクラスによって表されます。 ネットデバイス。 クラス ネットデバイス Node オブジェクトと Channel オブジェクトへの接続を管理するメソッドを提供します。 開発者はオブジェクト指向プログラミングの意味で専門化することができます。 このチュートリアルでは、NetDevice のいくつかの特殊なバージョンを使用します。 CsmaNetDevice, ポイントツーポイントネットデバイス и Wifiネットデバイス。 イーサネット ネットワーク アダプタがネットワークで動作するように設計されているのと同じように、 イーサネット, CsmaNetDevice で動作するように設計されています CsmaChannel, ポイントツーポイントネットデバイス で動作するように設計されています ポイントツーポイントチャネルと Wifiネットデバイス - で動作するように設計されています Wifiチャンネル.

4.1.5 トポロジカルアシスタント

実際のネットワークでは、ネットワーク カードが追加された (または組み込まれた) ホスト コンピューターが存在します。 ns-3 では、NetDevices が接続されたノードが表示されると言えます。 大規模なシミュレートされたネットワークでは、多くのオブジェクト間の接続を整理する必要があります。 Node, ネットデバイス и チャネル.

NetDevices をノードに接続し、NetDevices をリンクに接続し、IP アドレスを割り当てます。 ns-3 では一般的なタスクですが、これをできるだけ簡単にするために、いわゆるトポロジ ヘルパーが提供されています。 たとえば、NetDevice を作成するには、多くの ns-3 カーネル操作を実行し、MAC アドレスを追加し、ノードにネットワーク デバイスをインストールし、ノードのプロトコル スタックを構成して、NetDevice をチャネルに接続する必要があります。 複数のデバイスをマルチポイント リンクに接続し、個々のネットワークをインターネットワークス ネットワークに接続するには、さらに多くの作業が必要になります。 これらの多くの操作を使いやすいモデルに組み合わせたトポロジ ヘルパー オブジェクトを提供しています。

4.2 最初の ns-3 スクリプト

上記の方法でシステムをインストールした場合は、ホーム ディレクトリの repos というディレクトリに ns-3 リリースが存在します。 ディレクトリに移動 リリース

このようなディレクトリがない場合は、ns-3 のリリース バージョンをビルドするときに出力ディレクトリを指定しなかったことを意味します。次のようにビルドします。
$ ./waf configure —build-profile=release —out=build/release,
$ ./waf ビルド

次のようなディレクトリ構造が表示されるはずです。

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

ディレクトリに移動 例/チュートリアル。 そこに次の名前のファイルがあるのが見えるはずです。 最初の.cc。 これは、XNUMX つのノード間に単純なポイントツーポイント接続を作成し、ノード間で XNUMX つのパケットを送信するスクリプトです。 このスクリプトを XNUMX 行ずつ見てみましょう。これを行うには、first.cc をお気に入りのエディタで開きます。

4.2.1 定型コード
ファイルの最初の行はエディター モード行です。 エマックス。 これは、ソースコードで使用する書式設定規則 (コーディングスタイル) について emacs に伝えます。

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

これは常に非常に物議を醸す問題であるため、すぐに問題を解決するために記録を正す必要があります。 ns-3 プロジェクトは、ほとんどの大規模プロジェクトと同様に、提供されるすべてのコードが準拠する必要があるコーディング スタイルを採用しています。 コードをプロジェクトに貢献したい場合は、ファイルに記載されているように、最終的には ns-3 コーディング標準に準拠する必要があります。 doc/codingstd.txt またはプロジェクトの Web ページに表示されます。 https://www.nsnam.org/develop/contributing-code/coding-style/.

ns-3 コードのルック アンド フィールに慣れて、コードを操作するときは常にこの標準を適用することをお勧めします。 開発チーム全体と貢献者は、多少の不満はあったものの、これに同意しました。 上記の emacs モード行により、emacs エディターを使用している場合に正しくフォーマットすることが簡単になります。

ns-3 シミュレータは、次の方法でライセンスを取得します。 GNU一般公衆利用許諾契約書。 各 ns-3 配布ファイルには、適切な GNU 法的ヘッダーが表示されます。 多くの場合、以下に示すように、GPL テキストと作成者の上に、ns-3 プロジェクトに参加している機関のいずれかの著作権表示が表示されます。

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

4.2.2 プラグイン

コード自体は、一連のインクルージョン ステートメント (include).

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

高レベルのスクリプト ユーザーがシステム内に存在する多数のヘッダー ファイルに対処できるように、用途に応じてヘッダー ファイルを大きなモジュールにグループ化しています。 特定のモジュールで使用されるすべてのヘッダー ファイルを再帰的にロードする単一のヘッダー ファイルを提供します。 必要なヘッダーを正確に検索して依存関係の正しいリストを取得する代わりに、ファイルのグループを非常に細かい粒度でダウンロードできる機能が提供されます。 これは最も効率的なアプローチではありませんが、スクリプトの作成がはるかに簡単になることは確かです。

ns-3 の各インクルード ファイルは、次の名前のディレクトリに配置されます。 ns3 (ビルド サブディレクトリ) ビルド プロセス中のファイル名の競合を回避します。 ファイル ns3/コアモジュール.h ディレクトリにある ns-3 モジュールに対応します。 ソース/コア インストールしたリリースで。 このディレクトリのリストには、多数のヘッダー ファイルが含まれています。 組み立てを行うと、 ワフ パブリックヘッダーファイルをサブディレクトリのns3ディレクトリに配置します ビルド/デバッグ

このようなディレクトリがない場合は、ns-3 のリリース バージョンをビルドするときに出力ディレクトリを指定しなかったことを意味します。次のようにビルドします。
$ ./waf configure --build-profile=debug --out=build/debug
$ ./waf ビルド
または
$ ./waf configure --build-profile=optimized --out=build/optimized
$ ./waf ビルド

または 構築/最適化、構成に応じて。 ワフ また、すべてのパブリック ヘッダー ファイルをロードするためのモジュール インクルード ファイルも自動的に生成されます。 もちろん、あなたはこのガイドに忠実に従っているので、すでに完了しています。

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

例とテストを含むデバッグ ビルドを実行するようにプロジェクトを構成します。 あなたもそうでした

$ ./waf

プロジェクトを組み立てます。 それで、ディレクトリを見ると、 ../../ビルド/デバッグ/ns3をクリックすると、上に示した XNUMX つのモジュールのヘッダー ファイルなどが見つかります。 これらのファイルの内容を確認すると、対応するモジュールで使用されるすべてのパブリック ファイルが含まれていることがわかります。

4.2.3 ns3 名前空間

スクリプトの次の行 最初の.cc は名前空間宣言です。

using namespace ns3;

ns-3 プロジェクトは、ns3 という C++ 名前空間に実装されています。 これにより、すべての ns-3 関連の宣言がグローバル名前空間の外側のスコープにグループ化され、他のコードとの統合に役立つことが期待されます。 C++ 演算子を使用すると、ns-3 名前空間が現在の (グローバル) 宣言領域に導入されます。 これは、この宣言の後、すべての ns-3 コードで ns3::scope 権限演算子を使用する前に ns3::scope 権限演算子を入力する必要がないことを示す派手な方法です。 名前空間に詳しくない場合は、ほぼすべての C++ 教科書を参照し、std 名前空間と宣言を使用して nsXNUMX 名前空間を比較してください。 using namespace std; 出力演算子の使用例 COUT そしてストリーム。

4.2.4 ロギング

スクリプトの次の行は次のとおりです。

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

この声明は、文書システムについて話し合う便利な場所として使用します。 ドキシゲン。 ns-3 プロジェクトの Web サイトを見ると、ナビゲーション バーにドキュメントのリンクが表示されます。 このリンクをクリックすると、ドキュメント ページが表示されます。 「最新リリース」リンクから、ns-3 の最新の安定バージョンのドキュメントにアクセスできます。 「API ドキュメント」リンクを選択すると、ns-3 API ドキュメント ページが表示されます。

ページの左側には、ドキュメントの構造がグラフィカルに表現されています。 ns-3 ナビゲーション ツリーのモジュール ns-3 「ブック」から始めるとよいでしょう。 明らかにしたら モジュールをクリックすると、ns-3 モジュールのドキュメントのリストが表示されます。 上で説明したように、ここでのモジュールの概念は、上記のモジュールに含まれるファイルに直接関連しています。 ns-3 ロギング サブシステムについては、セクションで説明します。 ロギングモジュールの使用なので、このチュートリアルの後半でもう一度説明しますが、モジュールを見ることで上記のステートメントについて学ぶことができます。 基本そして本を開くと デバッグツールそしてページを選択します ロギング。 クリック ロギング.

ここでドキュメントを確認する必要があります ドキシゲン モジュール用 ロギング。 ページ上部のマクロのリストに、NS_LOG_COMPONENT_DEFINE のエントリが表示されます。 リンクをクリックする前に、登録モジュールの「詳細な説明」を参照して、一般的にどのように機能するかを理解してください。 これを行うには、下にスクロールするか、グラフの下の「その他...」を選択します。

何が起こっているかの概要を理解したら、次に進んで、特定の NS_LOG_COMPONENT_DEFINE のドキュメントを参照してください。 ここではドキュメントを複製しませんが、要約すると、この行は という登録コンポーネントを宣言します。 最初のスクリプトの例これにより、名前を参照してメッセージのコンソール ロギングを有効または無効にすることができます。

4.2.5 メイン機能

スクリプトの次の行では、次のようになります。

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

これは単にプログラム (スクリプト) のメイン関数の宣言です。 他の C++ プログラムと同様に、main 関数を定義する必要があります。これが最初に実行されます。 ここには特別なことは何もありません。 ns-3 スクリプトは単なる C++ プログラムです。 次の行は、時間解像度をデフォルトの 1 ナノ秒に設定します。

Time::SetResolution (Time::NS);

時間分解能、または単に分解能は、使用できる最小の時間値 (XNUMX つの時間間の表現可能な最小の差) です。 解像度は一度だけ変更できます。 この柔軟性を提供するメカニズムはメモリを消費するため、解像度が明示的に設定されるとメモリを解放し、それ以上の更新を防ぎます。 (解像度を明示的に設定しない場合、デフォルトで XNUMX ナノ秒になり、シミュレーションの開始時にメモリが解放されます。)

次の XNUMX 行のスクリプトは、アプリケーションに組み込まれている XNUMX つのログ コンポーネントを有効にするために使用されます。 エコークライアント и エコーサーバー:

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

ロギング コンポーネントのドキュメントを読むと、各コンポーネントで有効にできるロギング/粒度のレベルがいくつかあることがわかります。 これら XNUMX 行のコードにより、エコー クライアントとサーバーの INFO レベルへのデバッグ ログが有効になります。 このレベルでは、アプリケーションはシミュレーション中にパケットを送受信するときにメッセージを出力します。

ここからは、トポロジの作成とシミュレーションの実行に取り掛かります。 この作業をできるだけ簡単にするために、トポロジ ヘルパー オブジェクトを使用します。

4.2.6 トポロジー・アシスタントの使用

スクリプトの次の 3 行のコードは、シミュレーション内のコンピューターを表す Node ns-XNUMX オブジェクトを実際に作成します。

NodeContainer nodes;
nodes.Create (2);

続行する前に、クラスのドキュメントを探しましょう ノードコンテナ。 特定のクラスのドキュメントにアクセスするもう XNUMX つの方法は、タブを使用することです。 クラス ページ上で ドキシゲン。 すでに Doxygen を開いている場合は、ページの上部までスクロールして [クラス] タブを選択します。 新しいタブのセットが表示され、そのうちの 3 つはクラスのリストです。 このタブには、すべての ns-XNUMX クラスのリストが表示されます。 下にスクロールして、 ns3::NodeContainer。 クラスが見つかったら、それを選択して、そのクラスのドキュメントに移動します。

覚えているとおり、重要な抽象化の XNUMX つはノードです。 これは、プロトコル スタック、アプリケーション、周辺機器カードなどを追加するコンピューターを表します。 トポロジーアシスタント ノードコンテナ オブジェクトを作成、管理、アクセスするための便利な方法を提供します Node、シミュレーションを実行するために作成します。 上の最初の行は単に宣言しています ノードコンテナ、これをノードと呼びます。 XNUMX 行目は、ノード オブジェクトの Create メソッドを呼び出し、コンテナに XNUMX つのノードを作成するように要求します。 で説明されているように、 ドキシゲン、コンテナは ns-3 システムに XNUMX つのオブジェクトを作成するように要求します。 Node これらのオブジェクトへのポインタを内部に保存します。

スクリプトで作成されたノードはまだ何も行いません。 トポロジ構築の次のステップは、ノードをネットワークに接続することです。 私たちがサポートするネットワークの最も単純な形式は、XNUMX つのノード間のポイントツーポイント接続です。 これからそのような接続を作成していきます。

ポイントツーポイントヘルパー

使い慣れたパターンを使用してポイントツーポイント接続を作成し、トポロジ ヘルパー オブジェクトを使用して接続に必要な低レベルの作業を実行します。 XNUMX つの重要な抽象化を思い出してください。 ネットデバイス и チャネル。 現実の世界では、これらの用語は周辺機器カードとネットワーク ケーブルにほぼ対応します。 通常、これら XNUMX つは互いに密接に関連しており、デバイスなどの共有を期待できる人はいません。 イーサネット ワイヤレスチャネル経由で。 トポロジ ヘルパーはこの密接な関係に従っているため、このシナリオでは単一のオブジェクトを使用します。 ポイントツーポイントヘルパー ns-3 オブジェクトのセットアップと接続用 ポイントツーポイントネットデバイス и ポイントツーポイントチャネル。 スクリプト内の次の XNUMX 行は次のとおりです。

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

最初の行、

PointToPointHelper pointToPoint;

スタック上にオブジェクトのインスタンスを作成します ポイントツーポイントヘルパー。 トップレベルの観点から見ると、次の行は、

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

オブジェクトに伝える ポイントツーポイントヘルパー 値「5 Mbit/s」（XNUMX 秒あたり XNUMX メガビット）を「」として使用します。データレート'。

より具体的な観点から見ると、文字列「DataRate」はいわゆる属性に相当します。 ポイントツーポイントネットデバイス。 見てみると ドキシゲン 授業のために ns3::PointToPointNetDevice そしてメソッドのドキュメントでは GetTypeId デバイスに定義されている属性のリストが表示されます。 その中には「データレート」 ユーザーに表示されるほとんどの ns-3 オブジェクトには、同様の属性リストがあります。 次のセクションで説明するように、このメカニズムを使用して、再コンパイルせずにシミュレーションを簡単にセットアップします。

に似ている "データレート"PointToPointNetDevice では、PointToPointChannel に関連付けられた "Delay" 属性が見つかります。 最後の行

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

彼は話します ポイントツーポイントヘルパー 値「2 ms」(XNUMX ミリ秒) を、その後作成されるポイントツーポイント リンクの伝播遅延値として使用します。

ネットデバイスコンテナ

現時点ではスクリプトにあります ノードコンテナ、これには XNUMX つのノードが含まれます。 我々は持っています ポイントツーポイントヘルパー、オブジェクトを作成するために用意されています PointToPointNetDevices そして、PointToPointChannel オブジェクトを使用してそれらを接続します。 NodeContainer トポロジ ヘルパー オブジェクトを使用してノードを作成したのと同じように、次のように尋ねます。 ポイントツーポイントヘルパー 当社のデバイスの作成、構成、設置に関連する作業を当社に代わって実行します。 作成されたすべてのオブジェクトのリストが必要です ネットデバイス、したがって、私たちは使用します ネットデバイスコンテナ 以前と同じ方法で保管する ノードコンテナ 作成したノードを保存します。 次の XNUMX 行のコードは、

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

デバイスとチャンネルのセットアップを完了します。 最初の行は前述のデバイス コンテナを宣言し、XNUMX 行目は主な作業を行います。 方法 インストールを開始する オブジェクト ポイントツーポイントヘルパー 受け入れる ノードコンテナ パラメータとして。 内部 ネットデバイスコンテナ にある各ノードに対して ノードコンテナ が作成されます (ポイントツーポイント通信の場合は、ちょうど XNUMX つ必要です) ポイントツーポイントネットデバイス が作成され、デバイス コンテナーに保存されます。 ポイントツーポイントチャネル が作成され、それに XNUMX つアタッチされます PointToPointNetDevices。 オブジェクトを作成した後、 ポイントツーポイントヘルパー、作成されたオブジェクト内の対応する属性を初期化するために使用されます。

電話をかけた後 pointToPoint.Install (ノード) XNUMX つのノードがあり、それぞれにポイントツーポイント ネットワーク デバイスがインストールされ、それらの間に XNUMX つのポイントツーポイント リンクがあります。 どちらのデバイスも、チャネル上で XNUMX ミリ秒の送信遅延を伴い、XNUMX メガビット/秒の速度でデータを送信するように構成されます。

インターネットスタックヘルパー

これでノードとデバイスが構成されましたが、ノードにはプロトコル スタックがインストールされていません。 次の XNUMX 行のコードがこれを処理します。

InternetStackHelper stack;
stack.Install (nodes);

インターネットスタックヘルパー - ポイントツーポイント ネットワーク デバイス用の PointToPointHelper に似た、インターネット スタック用のトポロジ ヘルパーです。 方法 インストールを開始する NodeContainer をパラメータとして受け取ります。 実行すると、各コンテナ ノードにインターネット スタック (TCP、UDP、IP など) がインストールされます。

Ipv4アドレスヘルパー

次に、デバイスを IP アドレスに関連付ける必要があります。 IP アドレスの割り当てを管理するためのトポロジ アシスタントを提供します。 ユーザーに表示される唯一の API は、実際のアドレス配布を行うときに使用するベース IP アドレスとネットマスクの設定です (これはヘルパー内の低位レベルで行われます)。 サンプル スクリプトの次の XNUMX 行のコード 最初の.cc,

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

アドレス ヘルパー オブジェクトを宣言し、10.1.1.0 ビットマスクを使用して決定するために、ネットワーク 255.255.255.0 から IP アドレスの割り当てを開始するように指示します。 デフォルトでは、割り当てられるアドレスは 10.1.1.1 から始まり単調増加するため、このベースから割り当てられる最初のアドレスは 10.1.1.2、次に 3 というようになります。 実際には、低レベルでは、ns-XNUMX システムは割り当てられたすべての IP アドレスを記憶しており、同じアドレスが XNUMX 回生成される状況を誤って作成した場合に致命的なエラーを生成します (ちなみに、このエラーはデバッグが困難です)。

次のコード行は、

Ipv4InterfaceContainer interfaces = address.Assign (devices);

実際のアドレス割り当てを実行します。 ns-3 では、オブジェクトを使用して IP アドレスとデバイス間の接続を確立します。 Ipv4インターフェース。 後で使用するためにアシスタントによって作成されたネットワーク デバイスのリストが必要になる場合があるのと同じように、オブジェクトのリストが必要になる場合もあります。 Ipv4インターフェース. Ipv4インターフェースコンテナ はこの機能を提供します。

スタックをインストールし、IP アドレスを割り当てて、ポイントツーポイント ネットワークを構築しました。 次に、トラフィックを生成するために各ノードにアプリケーションが必要です。

4.2.7 アプリケーションの使用

ns-3 システムのもう XNUMX つの主要な抽象化は次のとおりです。 申し込み （応用）。 このシナリオでは、XNUMX つの基本クラスの特殊化を使用しています。 申し込み ns-3 と呼ばれる UdpEchoサーバーアプリケーション и UdpEchoクライアントアプリケーション。 前のケースと同様に、補助オブジェクトを使用して基本オブジェクトを構成および管理します。 ここで使用するのは UdpEchoServerHelper и UdpEchoクライアントヘルプ私たちの生活を楽にするためのオブジェクト。

UdpEchoServerHelper

first.cc サンプル スクリプト内の次のコード行は、前に作成したノードの XNUMX つで UDP エコー サーバー アプリケーションを構成するために使用されます。

UdpEchoServerHelper echoServer (9);

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

上記のスニペットのコードの最初の行は、 UdpEchoServerHelper。 いつものように、これはアプリケーションそのものではなく、実際のアプリケーションの作成に役立つオブジェクトです。 規則の XNUMX つは、必要な属性をヘルパー オブジェクトのコンストラクターに渡すことです。 この場合、サーバーがパケットをリッスンするポート番号が与えられない限り、ヘルパーは有益な操作を行うことができません。この番号はクライアントにも認識されている必要があります。 この場合、ポート番号をヘルパー コンストラクターに渡します。 コンストラクターは単に次のことを行います。 属性の設定 渡された値を使用します。 必要に応じて、後で SetAttribute を使用して Port 属性に別の値を設定できます。

他の多くの補助オブジェクトと同様に、オブジェクト UdpEchoServerHelper 方法があります インストールを開始する。 このメソッドを実行すると、基本的なエコー サーバー アプリケーションが効果的に作成され、ホストにバインドされます。 興味深いことに、その方法は、 インストールを開始する 受け入れる ノードコンテナ 他のパラメータと同様にパラメータとして インストールを開始する 私たちが見てきた方法。

ここで動作する C++ の暗黙的な変換は、メソッドの結果を受け取ります。 ノード.Get(1) (ノード オブジェクトへのスマート ポインターを返します - Ptr ) を使用し、匿名オブジェクトのコンストラクターで使用します。 ノードコンテナそれはメソッドに渡されます インストールを開始する。 C++ コードでどのメソッド シグネチャがコンパイルおよび実行されるかを判断できない場合は、暗黙的な変換を調べてください。

今ではそれがわかります echoServer.インストール アプリケーションをインストールしようとしています UdpEchoサーバーアプリケーション で見つかった ノードコンテナノード (インデックス 1 のノード) を管理するために使用します。 メソッド インストールを開始する すべてのアプリケーションへのポインタを含むコンテナを返します (この場合は、匿名のアプリケーションを渡したので XNUMX つ) ノードコンテナ、XNUMX つのノードを含む) はヘルパーによって作成されます。

アプリケーションはトラフィックの生成を開始するタイミングを指定する必要がある "始める" また、停止する時刻を追加で指定する必要がある場合もあります "停止"。 私たちは両方のオプションを提供します。 これらの時間は次のメソッドを使用して設定されます アプリケーションコンテナ 開始 и Force Stop。 これらのメソッドは、次のタイプのパラメータを受け入れます。 Time。 この場合、C++ 変換の明示的なシーケンスを使用して C++ を取得します。 1.0 を作成し、Seconds オブジェクトを使用して秒に変換する tns-3 Time オブジェクトに変換します。 変換ルールはモデル作成者が制御でき、C++ には独自のルールがあるため、パラメーターが期待どおりに変換されるとは限らないことに注意してください。 XNUMX行

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

これにより、エコー サーバー アプリケーションはシミュレーションの開始から XNUMX 秒後に開始 (自動的にオン) され、シミュレーションの XNUMX 秒後に停止 (オフ) になります。 XNUMX 秒後に実行されるシミュレーション イベント (アプリケーション停止イベント) を宣言したため、少なくとも XNUMX 秒間のネットワーク動作がシミュレートされます。

UdpEchoClientHelper

クライアントアプリケーション echo サーバーとほぼ同様の方法で構成されます。 ベースオブジェクトがあります UdpEchoクライアントアプリケーション、管理されている
UdpEchoClientHelper.

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

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

ただし、エコー クライアントの場合は、XNUMX つの異なる属性を設定する必要があります。 最初の XNUMX つの属性は作成時に設定されます UdpEchoClientHelper。 属性を設定するために (ヘルパー内で) 使用されるパラメーターを渡します。 「リモートアドレス」 и 「リモートポート」 必要なパラメータをヘルパー コンストラクターに渡すという合意に従って。

使ったことを思い出しましょう Ipv4インターフェースコンテナ 当社がデバイスに割り当てた IP アドレスを追跡するため。 インターフェイス コンテナ内のヌル インターフェイスは、ノード コンテナ内のヌル ノードの IP アドレスに対応します。 インターフェイス コンテナ内の最初のインターフェイスは、ノード コンテナ内の最初のノードの IP アドレスに対応します。 したがって、コードの最初の行 (上記) でヘルパーを作成し、クライアントのリモート アドレスがサーバーが配置されているホストに割り当てられる IP アドレスになることをヘルパーに伝えます。 また、パケットがポート XNUMX に送信されるように手配する必要があるとも言います。

「MaxPackets」属性は、シミュレーション中に送信できるパケットの最大数をクライアントに伝えます。 「Interval」属性はクライアントにパケット間の待機時間を指示し、「PacketSize」属性はクライアントにパケットのペイロードの大きさを指示します。 この属性の組み合わせを使用して、単一の 1024 バイトのパケットを送信するようにクライアントに指示します。

エコーサーバーと同様に、エコークライアントの属性を設定します。 開始 и Force Stop, ただし、ここではサーバーの電源がオンになってから XNUMX 秒後 (シミュレーション開始の XNUMX 秒後) にクライアントを起動します。

4.2.8 シミュレータ

この時点で、シミュレーションを実行する必要があります。 これはグローバル関数を使用して行われます シミュレーター::実行.

Simulator::Run ();

先ほどメソッドを呼び出したとき、

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

実際には、シミュレータで 1,0 秒、2,0 秒にイベントをスケジュールし、10,0 秒に XNUMX つのイベントをスケジュールしました。 電話の後 シミュレーター::実行を選択すると、システムはスケジュールされたイベントのリストの表示と実行を開始します。 まず 1,0 秒以内にイベントを起動し、エコー サーバー アプリケーションをトリガーします (このイベントは、他の多くのイベントをスケジュールすることができます)。 次に、t=2,0 秒にスケジュールされたイベントを起動し、エコー クライアント アプリケーションを起動します。 繰り返しになりますが、このイベントではさらに多くのイベントが予定されている可能性があります。 開始イベントのエコー クライアント実装は、サーバーにパケットを送信することによってシミュレーションのデータ転送フェーズを開始します。

サーバーにパケットを送信する行為により、バックグラウンドで自動的にスケジュールされる一連のイベントがトリガーされ、スクリプトで設定したタイミング パラメーターに従ってエコー パケットを送信する仕組みが実装されます。

その結果、送信するパケットは XNUMX つだけなので (属性を思い出してください)、 最大パケット数 XNUMX に設定されていた場合)、この単一のクライアント ping によって開始された一連のイベントが終了し、シミュレーションはスタンバイ モードになります。 これが発生すると、残りの予定されているイベントは次のイベントになります。 Force Stop サーバーとクライアント用。 これらのイベントが実行されると、さらに処理するイベントはなくなり、 シミュレーター::実行 制御を返します。 シミュレーションが完了しました。

あとは自分で後片付けをするだけです。 これは、グローバル関数を呼び出すことによって行われます。 シミュレーター::デストロイ。 ヘルパー関数 (または低レベルの ns-3 コード) が呼び出されたため、作成されたすべてのオブジェクトを破棄するフックがシミュレーターに挿入されるように編成されています。 これらのオブジェクトを自分で追跡する必要はなく、電話をかけるだけで済みました。 シミュレーター::デストロイ そして出て行きます。 ns-3 システムがこの面倒な作業を行ってくれます。 最初の ns-3 スクリプト first.cc の残りの行は、まさにそれを行います。

Simulator::Destroy ();
return 0;
}

シミュレータはいつ停止しますか?

ns-3 は、離散イベント (DE) シミュレーターです。 このようなシミュレーターでは、各イベントはその実行時間に関連付けられており、シミュレーションの進行に応じてイベントが発生した順序で処理されてシミュレーションが続行されます。 イベントにより、将来のイベントがスケジュールされることがあります (たとえば、タイマーは次の間隔でカウントを終了するようにスケジュールを変更できます)。

通常、初期イベントはエンティティによって開始されます。たとえば、IPv6 はネットワーク上のサービスの検出や近隣リクエストなどをスケジュールします。 アプリケーションは最初のパケット送信イベントなどをスケジュールします。 イベントが処理されると、ゼロ、XNUMX つ、または複数のイベントが生成されることがあります。 シミュレーションが進行するにつれて、イベントが発生し、終了するか新しいイベントが作成されます。 イベントキューが空の場合、または特別なイベントが検出された場合、シミュレーションは自動的に停止します。 Force Stop。 イベント Force Stop 関数によって生成される シミュレーター::停止 （停止時間）。

シミュレーションを停止するには Simulator::Stop が絶対に必要となる典型的なケースがあります。それは、自立したイベントがある場合です。 自立的 (または繰り返し) イベントは、常にスケジュールが変更されるイベントです。 結果として、イベント キューは常に空にならないようになります。 繰り返しイベントを含むプロトコルやモジュールは数多くあります。次に例を示します。

• FlowMonitor - 失われたパケットを定期的にチェックします。

• RIPng – ルーティング テーブル更新の定期的なブロードキャスト。

• など。

そのような場合 シミュレーター::停止 シミュレーションを正しく停止するために必要です。 さらに、ns-3 がエミュレーション モードの場合、RealtimeSimulator を使用してシミュレーション クロックとマシン クロックが同期されます。 シミュレーター::停止 プロセスを停止するために必要です。

教科書に載っているシミュレーションプログラムの多くは、 シミュレーター::停止 キューに入れられたイベントがなくなると自動的に終了するため、明示的に実行します。 ただし、これらのプログラムは Simulator::Stop 呼び出しも受け入れます。 たとえば、最初のプログラム例にある次の追加ステートメントは、11 秒での明示的な停止をスケジュールします。

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

この特定のシミュレーションは 10 秒後に自然に終了するため、上記は実際にはこのプログラムの動作を変更しません。 ただし、上記のステートメントの停止時間を 11 秒から 1 秒に変更すると、出力が画面に表示される前にシミュレーションが停止することがわかります (出力はシミュレーション時間の約 2 秒後に発生するため)。

Simulator::Run を呼び出す前に Simulator::Stop を呼び出すことが重要です。 そうしないと、Simulator::Run が stop! を実行するためにメイン プログラムに制御を戻せない可能性があります。

4.2.9 スクリプトの構築

シンプルなスクリプトの作成が簡単になりました。 スクリプトをスクラッチ ディレクトリに置くだけで、実行すると自動的にビルドされます。 ワフ。 やってみよう。 最上位ディレクトリに戻ってコピーします 例/チュートリアル/first.cc カタログへ スクラッチ

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

次に、次を使用して最初のサンプル スクリプトを構築します。 WAF:

$ ./waf

最初の例が正常に作成されたことを示すメッセージが表示されるはずです。

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
[614/708] cxx: scratch/myfirst.cc -> build/debug/scratch/myfirst_3.o
[706/708] cxx_link: build/debug/scratch/myfirst_3.o -> build/debug/scratch/myfirst
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (2.357s)

これで、サンプルを実行できるようになります (プログラムをスクラッチ ディレクトリにビルドする場合は、次のディレクトリから実行する必要があることに注意してください) スクラッチ):

$ ./waf --run scratch/myfirst

同様の出力が表示されるはずです。

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) Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.1.2

ここでは、ビルド システムがファイルがビルドされたことを確認し、それを実行していることがわかります。 エコー クライアントのコンポーネント エントリは、単一の 1024 バイト パケットをエコー サーバー 10.1.1.2 に送信したことを示していることがわかります。 エコー サーバー上のログ コンポーネントにも、1024 から 10.1.1.1 バイトを受信したことが表示されます。 エコー サーバーはパケットをサイレントに再生し、エコー クライアントのログでサーバーからパケットを受信したことがわかります。

4.3 ns-3 ソースコード

ns-3 ヘルパーの一部を使用したので、この機能を実装するソース コードの一部を見てみましょう。 最新のコードは、次のリンクにある Web サーバーで参照できます。 https://gitlab.com/nsnam/ns-3-dev.git。 そこには、ns-3 開発ツリーの Mercurial 概要ページが表示されます。 ページの上部にはいくつかのリンクが表示されます。

summary | shortlog | changelog | graph | tags | files

先に進み、ファイルのリンクを選択してください。 ほとんどのリポジトリのトップレベルは次のようになります。

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

サンプル スクリプトは次のディレクトリにあります。 例。 例をクリックすると、サブディレクトリのリストが表示されます。 サブディレクトリ内のファイルの XNUMX つ チュートリアル - first.cc。 をクリックすると 最初の.cc 学習したばかりのコードが表示されます。

ソースコードは主に次のディレクトリにあります。 SRC。 ディレクトリ名をクリックするか、ディレクトリ名の右側にあるファイルのリンクをクリックすると、ソース コードを表示できます。 src ディレクトリをクリックすると、src サブディレクトリのリストが表示されます。 次にコアのサブディレクトリをクリックすると、ファイルのリストが表示されます。 (このガイドの執筆時点で) 最初に表示されるファイルは次のとおりです。 中止します。h。 リンクをクリックすると 中止します。hのソースファイルに送信されます。 中止します。h、異常な状態が検出された場合にスクリプトを終了するための便利なマクロが含まれています。 この章で使用したヘルパーのソース コードは、次のディレクトリにあります。 src/アプリケーション/ヘルパー。 ディレクトリ ツリーを自由に探索して、何がどこにあるかを確認し、ns-3 プログラムのスタイルを理解してください。

出所： habr.com