メイン Routing Protocols Implementation & Model Development ユニキャストとブロードキャストについて | 投稿するにはまず登録を |
スレッド表示 | 新しいものから | 前のトピック | 次のトピック | 下へ |
投稿者 | スレッド |
---|---|
Thams | 投稿日時: 2009/9/30 15:34 |
半人前 登録日: 2007/10/3 居住地: 投稿: 26 |
ユニキャストとブロードキャストについて ルーティングプロトコルを組む際に、AODV等を参照すると
ユニキャストでは、
ブロードキャストでは、
のAPIが各々使用されています。 ?では、ユニキャストなのでRTS/CTS/DATA/ACKの処理で行われると思います。 ?は、ブロードキャストなのでNAVやキャリアセンスで周囲の通信が確認できなかったら通信すると思うのですが、関数で最後の引数delayは、どのような役割を果たしているのでしょうか?(バックオフでしょうか?) よろしくお願いします。 |
ipoten | 投稿日時: 2009/9/30 18:22 |
一人前 登録日: 2005/7/12 居住地: 投稿: 102 |
Re: ユニキャストとブロードキャストについて こんにちは
NetworkIpSendRawMessageToMacLayer() や NetworkIpSendRawMessageToMacLayerWithDelay() は、 IPレイヤやルーティングプロトコルから、MACに送信データグラムを渡すためのAPIなので、 MAC(802.11)内部で扱われるNAVやキャリアセンスやバックオフとはまったく関係ないと思います。 AODVで NetworkIpSendRawMessageToMacLayerWithDelay() を利用しているケースを見てみると、 確かに Hello や RREQ を送信する際に delay を設定していますね。 設定値は、マクロ AODV_PC_ERAND() を使用して、AODV_BROADCAST_JITTER (20ms) の範囲で乱数生成しています。 つまりブロードキャスト時に送信遅延揺らぎを意図的に生成しているということになります。 他のルーティングプロトコルでも同様の処理が行われているようです。 ネットワークの負荷と関係なく、送信時点でジッターを発生させるというのは、解せませんね。 プロトコルの特性上発生する何らかの現象をシミュレーションでモデル化しているのでしょうか・・・。 理由は調べてみないと分かりません。 もしかしたら、Hello や RREQ のように定期送信するパケットを、シミュレーション上で正確なタイミングで出すと、 他のノードとタイミングが一致した場合にブロードキャストなので全部ぶつかって落ちてしまうので、 意図的にジッターを入れてMACでキャリアセンスできるようにしているとか、そんな話かもしれません。 (たしかQualNetの講習会のプロトコル演習で、そんなケースをやったような) 参考になれば幸いです。 |
Thams | 投稿日時: 2009/9/30 21:22 |
半人前 登録日: 2007/10/3 居住地: 投稿: 26 |
Re: ユニキャストとブロードキャストについて 返信ありがとうございます。
NetworkIpSendRawMessageToMacLayerWithDelay()を追っていっても、 言われるとおり、引数のdelayがMAC内で呼ばれているような感じはありませんでした。 ipotenさんのご察しのように、キャリアセンスしやすくするためかもしれませんね。 (講習会に出ましたが、記憶が曖昧になってるので、資料を見てみようと思います ) |
スレッド表示 | 新しいものから | 前のトピック | 次のトピック | トップ |