Japan QualNet Community Forums Japan QualNet Community Forums
Welcome Guest 
ログイン
ユーザ名:

パスワード:


パスワード紛失

新規登録
検索
メインメニュー
アクセスカウンター
2024/04/29:12/13
2024/04/28:16/23

2024/02/29より291/1375
人気モジュール
No.1: フォーラム 20
日曜日からの合計
人気Browser&OS
No.1:巡回ロボット27

No.1:どっかの巡回ロボット26
No.2:Majestic-12巡回ロボット1

日曜日からの合計
メイン
   Routing Settings
     ルートが確定するまでの時間
投稿するにはまず登録を

スレッド表示 | 新しいものから 前のトピック | 次のトピック | 下へ
投稿者 スレッド
KIN
投稿日時: 2012/8/8 17:21
新米
登録日: 2012/6/25
居住地:
投稿: 17
ルートが確定するまでの時間
いつもお世話になっています。

現在、ルーティングプロトコルについてシミュレーションを行おうと考えています。
具体的には、シミュレーションをスタートしてから、初めにルートが決まって、
通信が開始されるまでの時間(初めのルートが確定するまでの時間)を測定したいと考えています。

そこで、正確に時間を計るにはどうしたらいいでしょうか?
アドバイスをお願いします。

hiro
投稿日時: 2012/8/8 18:22
長老
登録日: 2005/7/16
居住地:
投稿: 452
Re: ルートが確定するまでの時間
難しいですね、『経路表が完成した』という事象を確認すればよいのですけど、
Nodeやネットワークの構成により動的に経路表が変化することを考えると、
『完成した』というタイミングをどのように判断するのかが重要だと思います。

単に自NodeのNextHopだけが決まればよいわけではなく、
最終目的地までの全ての中継NodeのNextHopが定まらないと
実際のデータは届かないので、複数Nodeの経路表を観察する必要があります。

経路表はNetworkUpdateForwardingTable関数で更新されます。
また、経路表が更新されたタイミングを独自に知りたい場合は、
NetworkIpSetRouteUpdateEventFunction関数を使って自分の関数を
呼び出してもらうことも可能です。

これらの関数にログを入れたり、
NetworkPrintForwardingTable関数で経路表を実際に出力してみて、
『初めのルートが確定する』タイミングを自分で判断するしかないと思う。

安易な方法としては、
『経路表の内容が変化するのを観測し、最後に変化しなくなった時』
です。ただし、前回(Tn)と今回(Tn+1)で変化がなかったので、
前回(Tn)がルートが確定した時刻だった、という方法になります。
もちろん、ネットワークやシナリオ構成によっては、
いつまでたってもルートが確定しない場合もあります。
KIN
投稿日時: 2012/8/9 10:27
新米
登録日: 2012/6/25
居住地:
投稿: 17
Re: ルートが確定するまでの時間
返信ありがとうございます。

やはり難しいですか・・・
簡単な方法として、
ルーティングプロトコルとFTPなどのパケットを送信する
プロトコルでシナリオを構成して、FTPのパケット送信が
最初に始まる時間を経路表が完成した時間としようかなと
考えているのですが、そちらも難しいですか?
hiro
投稿日時: 2012/8/9 15:33
長老
登録日: 2005/7/16
居住地:
投稿: 452
Re: ルートが確定するまでの時間
ほとんどのアプリケーションは送信開始時刻が
.statファイルに出力されます。
FTPなら、FTP Client,First Packet Sent at (s)
CBRなら、CBR Client,First Packet Sent at (s)
です。

でも、送信開始時刻は.appファイルに設定する時間に依存しますよね。
FTPの場合は、開始時間になってからサーバとクライアント側で
TCPコネクションの確立処理が開始されて確立してから、
初めてデータ転送が始まりますが、
CBRの場合は、開始時間になるとUDPパケットを即座に送信します。
つまり、CBRの場合はルーティングが確立しなくても勝手に送っちゃいます。

また、仮にルーティングの確立が時刻10秒で完了している場合に、
FTPを時刻20秒で開始するとパケットの送信は時刻20秒以後になります。

計測したいのは、
『ルートが確立する時刻』ですか、
それとも『パケットを送信する時刻』
あるいは『パケットを受信した時刻』

時刻を計測する状態をきちんと整理した方が良いと思います。

例えば全く同じNode構成のシナリオで、
以下の2種類の.app指定でシナリオを実行してみます。

CASE1 FTPをゼロ秒から
FTP 1 2 100 0S
結果を.statから抜粋すると、
1,,[1],Application,FTP Client,First Packet Sent at (s) = 5.687660373
2,,[2],Application,FTP Server,First Packet Sent at (s) = 5.714571731
約5.6秒でTCPコネクションが張られて送信開始。

CASE2 CBRをゼロ秒から
CBR 1 2 100 512 1S 0S 0S PRECEDENCE 0
結果を.statから抜粋すると、
1,,[1024],Application,CBR Client,First Packet Sent at (s) = 0.000000000
2,,[1024],Application,CBR Server,First Packet Received at (s) = 11.132263707
時刻ゼロ秒で送信開始しているけど、
最初に届いたのは約11.1秒です。

流すアプリケーションでこれだけ挙動が変化します。
単にアプリケーションで判断するのは、個人的にはお勧めしにくいです。
KIN
投稿日時: 2012/9/2 20:12
新米
登録日: 2012/6/25
居住地:
投稿: 17
Re: ルートが確定するまでの時間
返信ありがとうございます。

とりあえずですが、
サーバとクライアント側で
TCPコネクションの確立処理が開始されて確立する時間で判断していきたいと思います。

思うような結果が出ない場合には再度相談させていただきます。
スレッド表示 | 新しいものから 前のトピック | 次のトピック | トップ
Copyright c KOZO KEIKAKU ENGINEERING Inc. All Rights Reserved.
XOOPS Cube PROJECT