こんばんは
QuaLnetのGUI機能にて以下の環境で次の３つの項目の値を確認しましたが、３つの項目の結果に矛盾が生じ、どう解釈すればいいのかわからなかったので、質問させていただきました。

【統計項目】
Peak Queue Size
TotalPacketsDropped
TotalPacketsReceived

【ネットワーク環境1】
Qualnet5.0.2
Routing Protocol：OLSR-inria
上記のものを使用しています。

以下電波範囲変更(150m間隔の格子状で行う際に用いる設定のようです。)
Radio Type 802.11a/g Radio
Transmission Power at 6 Mbps 8.0
Transmission Power at 9 Mbps 8.0
Transmission Power at 12 Mbps 10.0
Transmission Power at 18 Mbps 18.0
Transmission Power at 24 Mbps 18.0
Transmission Power at 36 Mbps 16.0
Transmission Power at 48 Mbps 16.0
Transmission Power at 54 Mbps 16.0

GUIにて150m間隔の10*10の格子状ネットワークを作成し、以下の通信を行わせました。
最下段中央の51番ノードから最上段中央の60番ノードまでCBR通信
左端中央の5番から右端中央の95番ノードまでCBR通信

この２つのＣＢＲ通信はStatic routingで行っています。
51〜59(55番ノードは、もう片方のCBR通信も行うので除く)
5,15,25,35,45,65,75,85番ノード
55番ノードに専用のroutes-staticファイルを持たせることで
51->52->53->54->55->56->57->58->59->60のCBR通信と
5->15->25->35->45->55->65->75->85->95のCBR通信を行わせています。

Staticファイルは添付させていただきました。
【Nodes】→【RoutingProtocol】→【Specify Static Routes】からファイルを読み込めます。


51->60のCBR通信　5->95のCBR通信両方とも同じ設定です。
items to send 4000
item size 512byte
interval 10millsecond
start 100s
End 140s

シミュレーション時間 200s

全てのノードとインターフェースで
Number of IP Output QueueSize=１に設定してあります。
【Network Layer】→【Schedulers and Queues】→【Number of IP Output QueueSize=3→1】

【Interferce】と【Nodes】の両方の項目で55番ノードを（CBR通信が交差するノード）
【Network Layer】→【Schedulers and Queues】→【IP Input Queue Size】=2000に変更しました。

【統計結果】
TotalPacketsReceived 3926(60) 3946(95) //統計値(宛先ノード番号)
TotalPacketsDropped 2(55)　//統計値(パケット落ちした中央のノード番号)
Peak Queue Size(byte) 1684(55)　//統計値（中央のノード番号）
【QualNet.1.22.12_21.07.03.stat】(添付させていただきました)

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
【ネットワーク環境2】
ネットワーク環境1と基本的には同条件です。
変更点は
51->52->53->54->55->56->57->58->59->60のCBR通信
5->15->25->35->45->55->65->75->85->95のCBR通信
この２つのCBR通信に以下のCBR通信を追加しました。

71->72->73->74->75->76->77->78->79->80->70->60のCBR通信
このCBR通信も同じくStatic routingで行っています。
それぞれ関連するノードにStaticファイルを持たせてあります。（75番ノードは2つのCBR通信が交差する点なので55番ノードと同じく専用のStaticファイルを用意）

5->95のCBR通信はネットワーク環境1と同様です。

51->60のCBR通信はitems to sendを4000→1000に変更
71->60のCBR通信はitems to sendを3000に設定しました。
（4000パケットを擬似的に分断させて送信）

TotalPacketsReceived　3872(60)　3888(95)　//統計値(宛先ノード番号)
TotalPacketsDropped　135(55)　//統計値(中央のノード番号)
Peak Queue Size(byte) 1812(55)　//統計値（中央のノード番号）
【QualNet.1.22.12_21.26.20.stat】
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

【結果に対する疑問点】
ネットワーク環境1、ネットワーク環境2どちらについてもいえることですが、55番ノードのOutputqueueSizeは2000byteに設定しました。
55番ノードのPeak Queue Sizeはどちらの環境でも2000を超えていません。にもかかわらず55番でパケット落ちが発生しているのは何故でしょうか？Peak Queue SizeがQueueSizeを超えていないのにパケット落ちが発生している疑問。

ネットワーク環境?では51->60に対して4000パケットを送信していました。ネットワーク環境?で51->60に対する送信パケットは1000パケットに減らしたにも関わらず、ネットワーク環境?での55番のパケット落ちが増してしまったのは何故なのでしょうか？
普通に考えたら、4000パケット送っていたのが1000パケットになったのだから4000パケットを送っていた時よりパケット落ちが発生することはないはずです。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
staticファイル、２つの統計結果(statファイル)とットワーク環境?のconfigを添付させて頂きました。
ネットワーク環境1に関しては、必要であれば添付致しますが、2のconfigから追加したCBR通信を消し、Noedsに設定したStatic RouteをNOに戻し、送信量を1000->4000に変更すれば簡単に再現できます。

GUIやプログラムなど色々な点からパケットを分散させることで、統計値がよくなるようなネットワーク環境づくりを目指していますが、想定している結果と実際の結果がまったく違うためどう対処し次に何をするべきなのかが見えてこない現状です。
ご回答よろしくお願いします。

10kake10_matome.zip

Queueに1812Byetたまっている時に、540Byteのパケットが到着したら
1812 + 540 > 2000で格納できないのではないでしょうか。

環境1->環境2で、55番のパケット落ちが増加した原因は、ぱっと思いつきませんでした。

一つ疑問ですが、routing protocolをOLSRにして、static route設定は効くのでしょうか。

gogoteaさん、横からすいません。

問題点に関してはさらっと目を通しただけですが、scallionさんのコメントが気になったのでちょっとだけstatファイルをのぞいてみました。

パッと見た感じではOLSRのパケットが全端末で(55番でも)流れていますね。
static routeの設定ができているかは確認していませんが、少なくともOLSRが優先されているのではないでしょうか？

CBRでA→B→C→Dと設定したとありますが、A→Dしか設定できないです。
A→B→C→Dはstatic routeでの設定となります。

動きを想定して設定をしていると思いますが、想定通りに動いてるのか確認することをお勧めいたします。

転送経路はプログラムを変えなくてもデバッガで追いかけられますよ。
大変であればシナリオを小さくすれば問題の切り分けがしやすくなると思います。

scallionさん、hedさん回答ありがとうございました。
お二方から「StatiRoutingができていないのではないか」という指摘を受けましたが、結論から書くと
「Static Routingはできています。」
CBR通信の開始時間とともにGUIのアニメーション上で、Static Routeを通ったマルチホップ通信が確認できています。

「CBRでA→B→C→Dと設定したとありますが、A→Dしか設定できないです。
A→B→C→Dはstatic routeでの設定となります。」
→Static routingでCBR通信をA→B→C→Dでやっているという意味です。

「転送経路はプログラムを変えなくてもデバッガで追いかけられますよ。
大変であればシナリオを小さくすれば問題の切り分けがしやすくなると思います。」
→以前3kake3のシナリオでパケットのフォワーディングをデバッグで追いかけようとしたことがありますが、
結論から書くと、ある程度の検討はつけましたが、どのファイルのどのソース部分（関数）でいつデータパケットのフォワーディングを行っているか正確に追い切ることができませんでした。
この点が分かると自分の研究に大変役立つので捕捉していただけると幸いです。

まず、フォワーディングではなく、どうなって初めて統計値のTotalPacketsDroppedが表示されるのかということが気になり、
この統計値を出力してるソース部分を探しました。
以下該当部分：if_queue.cpp
sprintf(buf, "Total Packets Dropped = %u", (Int32)numPacketsDropped);

numPacketsDroppedがどう変動していくかをプログラムで追い、最終的にパケット落ちを判断する式を発見しました。
以下該当部分：if_queue.cpp
if (MESSAGE_ReturnPacketSize(msg) > (queueSizeInBytes - bytesUsed))

このif文の条件によりパケット落ちが発生するかどうかの判定をしています。
if文直後のプログラムの先頭にブレークポイントをつけF5（デバッグ）を押したところ、
コマンドプロンプト上でCurrentSimTimeが表示され、この時のCurrentSimTimeの値がCBR通信開始の時間であったこと
【Nodes】→OutputqueueSize=2001に変更しましたが(55番でパケット落ちをさせようとした)
このパケット落ち判定式を通過した時のqueueSizeInBytesの値が2001であったことからこれがパケット落ち判定式であることは間違いないといえます。
しかし、私はこの2001という値が55番ノード（3kake3シナリオの場合は5番ノード）のOutputqueueSizeであることを自分で設定したので知っていますが、プログラミング上で、どうやって55番ノードでinterferceであるのかを指しているのかが分かりませんでした。
デバッグ途中にローカルで全ての変数を見ましたが、55番ノードに関連した変数はないようにみえました。
（160.0.0.55を一度2進数に変換してから10進数に戻すと=2835349559になります。ですがこの値はありませんでした。）

F5を一度押したことにより、今パケット落ちが発生し、これからデータパケットのフォワーディングが続くはずだと思った私は
このパケット落ち判定式を一度通ってから次にもう一度通るまでの間でパケットのフォワーディングを行っている関数があると考えました。
Forwarding関連の関数はたくさんあるわけですが、この方法で以下の２つの関数でパケットのフォワーディングを行っているのではないかと見当をつけました。

RouteThePacketUsingLookupTable()
↓
NetworkGetInterfaceAndNextHopFromForwardingTable()

3kake3のシナリオでは以下のような流れでStatic Routingを行っています。
2->5->8
4->5->8

デバッグを続け
NetworkGetInterfaceAndNextHopFromForwardingTable()の中で
destinationAddress=2835349512
nextHopAddress=0x001242f4
interferceIndex=0x001242ec
など関連深い変数が変動するわけですが、この数値が何を表しているのかが分かりませんでした。
destinationAddressに関しては「2835349512」この数値を2進数に直し8bitずつに分けてから10進数に変換したところ
169.0.0.8とデータパケットの宛先端末を表す数値に変換できたわけですが、
nextHopAddressとinterferceIndexが表している数値が何なのかわからず追いきることができません。
またこの関数内にはディスティネーションの変数が２つあったりします。
単独であるもの（destinationAddress）、fowardTable構造体→row構造体の中にあるdestaddress
フォワーディングに関して自分が取り組んだことをまとめてみました。
結局デバッグで追い切ることができまえんでした。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
分からない点・知りたい点のみピックアップします。
・メイントピックで挙げた、PeakQueueSizeを超えていないのにパケット落ちが発生している矛盾と
4000パケット送っていた時よりも1000(残りの3000は別ルートで分散)パケット送ったときのほうがパケット落ちしてしまった矛盾の原因

・以下の２つの変数が表す数値からどうやってIPアドレスを入手できるのか
nextHopAddress=0x001242f4(10進数に変換すると1196788)
interferceIndex=0x001242ec(10進数に変換すると1196780)

・パケットのフォワーディングをしている様子をデバッグで追いたいがその際に見る関数は
RouteThePacketUsingLookupTable()
NetworkGetInterfaceAndNextHopFromForwardingTable()
この関数であっているのかどうか

・if_queue.cpp
if (MESSAGE_ReturnPacketSize(msg) > (queueSizeInBytes - bytesUsed))
この式でqueueSizeInBytes=2001が55番ノード(私がQutputQueuesizeを変更したところ、3kake3シナリオでは5番)だとわかりますが、
プログラム上ではどうやって55番ノードであることを識別しているのか。
55番のＩＰアドレスを表すような変数はローカルにはなかった気がします。
（160.0.0.55を一度2進数に変換してから10進数に戻すと=2835349559になります）

すぐにわかる部分だけ書きます。
StaticRouteの設定がやはり気になります。

引用：
前にも書きましたが、例えばPeakQueueSizeだけQueueにあるとしたときにCBRパケット(512Bytes＋ヘッダ)は入らないと思います。
if (MESSAGE_ReturnPacketSize(msg) > (queueSizeInBytes - bytesUsed))
このifの中でDropしていますよね。

引用：
ルーティングの問題の様な気がしています。まだ確証はありませんが。

引用：
変数のアドレスではないでしょうか。
中身をみたら、interfaceIndex: 0, nextHopAddress: 2835349519等の値が入っていました。あくまで一例です。

引用：
ForwardPacketというそのまんまの名前を持った関数を見つけました。

引用：
node構造体の中身を見てみてください。

scallionさんアドバイスありがとうございます。
お二方のご指摘を参考にし以下の２つの検証を行ってみました。

ForwardPacket関数も実はすでに見つけていたのですが、StaticRoutingを行っていたシナリオでデバッグをしたところ
desaddressの値がGUIで設定していた宛先ノードIPアドレスと一致していなかったため、この関数は無視していたのですが、
再度、ルーティングミスのご指摘いただいたので、一度OLSRでStaticRouteを用いなかった時のForwardPacket関数の動作を追いました。


【まず最初に】：
「olsrのみでルーティングを行ったシナリオではForwardPacket関数での動作とGUI画面の【Output windows】に表示させた
ルーティングテーブルを追った時の結果が一致しました。(検証1)
今回登場する３つのシナリオは全て１つのCBR通信しか用意していません。
今回追った変数はpreviousHopaddress,noedId,desaddress,nexthopaddressの４つです。

【検証１】olsrのみでルーティングを行った際のForwardPacket関数の動作チェック
routing_olsr-inria.cppファイルの↓の値を0から1に変えるとGUI上の【Outputwindow】にルーティングテーブルが表示されます。
#define DEBUG_OUTPUT 0

【OutputWindow】にて1->2->5->6->9このようにCBR通信がマルチホップされていることが分かりました。
このパケットの流れの動作を確認するためにForwardPacket関数の以下の行の先頭にブレークポイントを設置しました。
●NetworkDataIp *ip = (NetworkDataIp *) node->networkData.networkVar;

NetworkDataIp構造体の中にforwardTable構造体があり、さらにこの中にrow構造体があります。
row構造体のメンバ内にdesAddressとnextHopAddressがあります。
previousHopaddressはForwardPacket関数の引数としてあり、noedIDも引数として読み込まれます。

【実際のルート】1->2->5->6->9
【捕捉】addressに関しては実際は2835349505　このような数値で出力されますが、わかりづらいためここでは、
この数値をIPアドレスに変換した場合の最後の１ケタの数字のみを書いてあります。(数値を2進数に変換→8bitずつに区切り10進数に再度変換することでIPアドレスが得られます。)
2835349505→169.0.0.1→1と書いてあります。
IPアドレスと実際のノード番号のずれがないことは事前に確認済みです。

スタート(F5(デバッグ))→ステップイン(F11)
【デバッグ結果】
previousHopaddress=1
noedId=2
desaddress=9
nexthopaddress=5

↓F5＋F11

previousHopaddress=2
noedId=5
desaddress=9
nexthopaddress=6

↓F5＋F11
previousHopaddress=5
noedId=6
desaddress=9
nexthopaddress=9

以下この流れをループしました。
この動作から1->2->5->6->9のうち2->5->6->9とマルチホップしたことが確認できました。
【疑問点１】
1->2を更新した部分がForwardPacket関数に入るまえに行われたことが考えられますが、visual studioの呼び出し機能などを
使っても中々把握できない現状です。これを把握するにはどうすればいいでしょうか？
上で挙げた流れを考慮すると
previousHopaddress=null
noedId=1
desaddress=9
nexthopaddress=2
となる瞬間があるはずだと考えているのですが、このように変化するポイントが見つかりません。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
【検証２】
OLSRを動かしつつStaticRoutingはできないないのではないか？という指摘をいただいたので以下のことを検証してみました。
GUI上で【Nodes】と【Networks】からRouting Protocolをolsr_inriaに設定した場合と
Bellmann Ford(デフォルトでこの設定になっている)に設定した場合で、3kake3の格子上のネットワークにて
1->4->7->8->9->6->3->2このようなStaticRoutingを行わせるように設定しました。
Staticファイルは添付しておきました。(2番と5番以外にこのStaticファイルを持たせています。)
少なくともGUI上では確実にStaticRouteで設定したRouteを通っていることが確認できています。
しかし検証１と同様にForwardPacket関数を追ってみたところ以下のような結果になってしまいました。

previousHopaddress=1
noedId=4
desaddress=9
nexthopaddress=5

↓F5+F11
previousHopaddress=4
noedId=7
desaddress=9
nexthopaddress=8

↓F5+F11
previousHopaddress=7
noedId=8
desaddress=9
nexthopaddress=9
//ここで目的値にたどりついたのかと思いましたが..以下につながる

↓F5+F11
previousHopaddress=8
noedId=9
desaddress=8
nexthopaddress=8
以下の変数の変動は確認していません。

まずdesaddress=9になっている時点でおかしいことがわかります。
宛先受信端末ノードは2番に設定してあります(1->4->7->8->9->6->3->2)

【疑問点２】
結局,StaticRoutingは設定できいないということなのでしょうか。
デフォルト設定のBellmann FordでもStaticRoutingの動作がForwadPacket関数で確認できなかったわけですが、
結局StaticRoutingとは何だったのかという疑問が残ります。

【疑問点３】
GUI上では間違いなくStaticRouteを通っているわけですが、ForwardPacket関数内とは別のところで
StaticRoutingを用いたフォワーディングが行われれていたか、ForwardPacket関数での謎のフォワーディング動作が行われてしまい
、本題であるパケットを分散したにも関わらず結果が逆に悪くなってしまったことにつながったと考えるべきでしょうか。
そうだとした場合はForwardPacket関数を読み込んでいる部分を全てコメントアウトすれば、期待通りの結果が得られるのか（これは後日また検証しています）

【疑問点4と仮説】
検証１に書いたようにStaticRoutingを用いない場合ではForwardPacket関数での動作をほぼ追えたわけですが、
その際に、このForwardPacket関数が何回デバッグで通過したのかを確認しました。
結果は1200回、ForwardPacket関数がデバッグされました。

検証１に挙げた通りnexthopaddress=9になる（宛先端末ノードに到達する）のに３回
このForwardPacket関数を通過することが簡単に確認していただけるかと思います。
つまり,宛先端末ノードに到達するのに必要なデバッグ回数は3回ということ。
1200/3=400

実はこの400という数字は1番から9番に送信させたときのItems to sendの値を一致します。
何がいいたいかというと、QualNetでは（少なくとも本シナリオでは）１パケットずつソースプログラム上で
送信しており、現在送っているパケットが宛先端末ノードにたどりついてから、次のパケットを送信する。
このプロセスを400回繰り返し、400パケット宛先端末ノードに送信しているということです。

StaticRoutingの未だによくわからない現象により、トラフィックの分散による結果がよくならないということに、悩まされているわけですが、
もし上で挙げた仮説を真とした場合、この関数に通った回数が300を超えたら
previousHopaddress,noedId,desaddress,nexthopaddressこれらの値を下記の直後で変更することで、
StaticRoutingを用いなくても、パケットの分散をすることができ、(400パケットを300パケット用のルートと100パケット用のルートで分断)期待通りの結果が得られるのではないかと考えているのですが
どうでしょうか？

●NetworkDataIp *ip = (NetworkDataIp *) node->networkData.networkVar;

この方針で今後頑張っていこうと考えているわけですが、ここで疑問点１が浮上し
1->2->5->6->9の流れのうち、1->2の経路選択を変更できない点に悩まされています。

情報が不足してる点などがあれば、ご指摘いただければ捕捉いたします。
アドバイスしていただけると幸いです。よろしくお願いします。


添付ファイル：
1to9_NoStatic_olsr：検証１用のシナリオ
1to2_14789632：検証２用のolsr+static
Bellmann_Ford_static:検証２用のBellmann Ford用のStatic

1月28日まとめ.zip



＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
【追記】1月28日
お恥ずかしながら、RoutingProtocolの選択の覧に【None】があることに気づきました。これを知らなかったので上記の検証2で、RoutingProtocolを態々デフォルトのBellmann Fordを選択していたわけですが...

Routing Protocolを【None】にしたうえで、Static Routingを設定し
ForwardPacket関数の動作を追ってみたところ。
GUIのアニメーション画面、ForwardPacket関数の動作の両方でStaticRoutingで設定した経路を通っていたことを確認しました。
つまり、お二方からご指摘いただいた通り、Routingの設定がうまくいっていなかった模様です。
ただ未だに何故GUI画面ではStatic Routeを通っていたのかが分かりません。とりあえず、この理由は今すぐに知る必要はないのですが、やはり
疑問点１に書いたように、1->2へとパケットをフォワーディングする部分がソースプログラム上で見つかりません。

【疑問点１】
1->2を更新した部分がForwardPacket関数に入るまえに行われたことが考えられますが、visual studioの呼び出し機能などを
使っても中々把握できない現状です。これを把握するにはどうすればいいでしょうか？
上で挙げた流れを考慮すると
previousHopaddress=null
noedId=1
desaddress=9
nexthopaddress=2
となる瞬間があるはずだと考えているのですが、このように変化するポイントが見つかりません。

読むのに結構時間がかかってしまいました。。
情報がちょっと多すぎるかも・・？（少なすぎるのも問題ですが・・難しいですね。）

それはさておき、
引用：

1からスタートしたのであれば、1->2はForwardとは言わないのではないでしょうか。
NetworkIpSend〜〜ではないでしょうか。（未確認です）


引用：
矢印の流れを見て判断されたのでしょうか。
GUI表示にはあまり詳しくないですが、矢印で判断するのは難しいと思いますよ。
OLSR+Staticの時は、OLSRのパケットも出ていたでしょうし。
一瞬しか矢印が出なかったり、タイミングがちょっとずれることもあるかと思います。