Я даже не смог запустить симуляцию с неизмененным вашим кодом, потому что были неподключенные ворота. (И есть небольшие раздражающие несоответствия между именами файлов и модулей со словами Node
и Module
, но это не относится к делу.)
Чтобы решить эту проблему, вам нужно изменить сегмент connections
вашего модуля Node
на нечто похожее на то, что есть в модуле Node
образца routing
примера моделирования, включенного в OMNeT ++:
module Node
{
gates:
inout g[];
submodules:
floodingModule: FloodingNode;
connections:
for i=0..sizeof(g)-1 { // <= this is the important part
g++ <--> floodingModule.g++;
}
}
Дело в том, что для каждого "внешнего" соединения между Node
s в сети должно быть соответствующее соединение (для продолжения пути) внутри модуля Node
(на каждом конце), между ним и субмодуль floodingNode
. «Автоматическое объединение / расхождение» путей соединения в векторах затвора на границах составного модуля отсутствует.
Да, это означает, что если у любого данного узла есть, скажем, пять других узлов, связанных с ним на одном и том же векторе ворот, то внутри этого узла должно быть пять «параллельных» соединений, все из которых ведут к вектору затвора субмодуль - в данном случае.
И не нужно ни спецификатора allowunconnected
, ни свойства @loose
нигде, в этом случае они приносят больше вреда, допуская «недействительные» сети, чем пользы. В любом случае, они в основном полезны для беспроводного моделирования.
Кроме того, вы должны рассмотреть только планирование простого «таймерного» собственного сообщения (даже если оно в T=0
) в initialize()
и отправку «настоящих» сообщений в методе handleMessage()
при получении указанного таймера, таким образом, визуализация графической среды работает лучше, и это также возможно лучший дизайн.