こんにちは
いつもお世話になっています

現在送信先のノードから送られたパケットをほぼ無条件(ttl、ループバックなどを除く)で再送信してこれを繰り返し力技的に1つの宛先への到達を目指すfloodingプロトコルをコーディングしています

floodingの動きがDSRやAODVのRREQにそっくりなため私はDSRを元にしてソースを書き換えています

通常RREQはCBRなどのアプリケーションから送信要求が発生した時に送信されるので、ここを強制的に送信するようにソースを改変しました

具体的にはtxtファイルなどでappファイルのような形式のもの作り、それをinitで読み込んで構造体に格納します。
DsrSetTimerイベントで1秒ごとにその構造体をチェックし、自分が送信ノードでsimtimeが送信時間と同一ならmessageをallocしてそれをDsrRouterFunctionに送り、強制的にRREQを送信します。

こうしたところ、発生させるRREQが1個のときは問題が無いのですが、12個目あたりからUnknown Dsr packet typeのエラーが発生します。
何度か試したところmessage.cppの方でメモリが足りないようなエラーが発生していたので、おそらく1度にmessageをallocしすぎてメモリ不足担っていると思うですが、これを回避するために何か方法はあるでしょうか？

検討されているプロトコルについて、ちょっと理解しきれなかったのですが
QualNetのプログラミング/デバッギングの観点から3点ほど。

単純な話なのですが、allocしたmessageを解放しているでしょうか？
Message構造体の基本的な流れは
MESSAGE_Allocで生成→MESSAGE_Sendで配送→受け取り側でMESSAGE_Freeで(1度だけ)解放
という感じですが、これは正しく行われているでしょうか？

また、"Unknown Dsr packet type"は
関数DsrHandleOptions内の*optionsによる分岐で
当該タイプが見つからない、かつoptionSizeが0の時に出ますね。
これら、optionsもしくはoptionSizeの値がどのようになるべきか
(そもそも間違った値をセットしていたなどということはないか)
確認してみてはいかがでしょうか？

ちょっと無理矢理なアプローチですが
Message絡みで"12"というマジックナンバというとmessage.hで
#define MAX_INFO_FIELDS 12
というのが見つかりました。もしMessageのInfo領域を使用した
プログラミングをしている場合、このあたりを疑ってもいいかもしれません。