(OMNeT++) Куда идут пакеты?

Я пытаюсь выполнить проект, описанный также здесь: 0

Я изменил файл UdpBasicApp.cc в соответствии со своими потребностями и добавил в функцию handleMessage() фрагмент кода для получения длины очереди Ethernet маршрутизатора. Однако возвращаемое значение всегда равно 0.

Мой файл .ned, касающийся очереди маршрутизаторов, таков:

**.router*.eth[*].mac.queue.typename = "DropTailQueue"
**.router*.eth[*].mac.queue.packetCapacity = 51

Код, добавленный в файл UdpBasicApp.cc, выглядит следующим образом:

cModule *mod = getModuleByPath("router3.eth[*].mac.queue.");                 
queueing::PacketQueue *queue = check_and_cast<queueing::PacketQueue*>(mod);  
int c = queue->getNumPackets();

Итак, мой вопрос таков: это правильный способ создать очередь в маршрутизаторе, связанном с другими узлами с помощью Ethernet-соединения? Я сомневаюсь, что, возможно, пакеты не проходят через указанный интерфейс, т.е. я установил параметры ini для неправильной очереди.


c++ queue router omnet++ inet
person SuperFluo    schedule 25.01.2021    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Вы не создаете эту очередь. Он уже был создан ядром OMNeT++. Вы просто получаете ссылку на уже существующий модуль с вызовом getModuleByPath().

Путь к модулю router3.eth[*].mac.queue. в этом вызове довольно подозрительный. Во всех приложениях жестко закодировано получение длины очереди из router3, даже если приложение установлено в router1. т.е. вы пытаетесь посмотреть длину очереди в совершенно другом узле. Тогда eth[*] неверно. Поскольку маршрутизатор, очевидно, содержит более одного интерфейса Ethernet (иначе это не был бы маршрутизатор), вы должны явно указать, какой интерфейс вы хотите выделить. Вы не должны указывать шаблоны в пути к модулю (т.е. eth[0] или что-то в этом роде, с точным индексом должен быть указан). И в этот момент вы должны ответить на вопрос, какой ethernet-интерфейс меня интересует, и указать этот индекс. Наконец, конец . конец также недействителен, поэтому я считаю, что ваш код никогда не выполняется, иначе часть check_and_cast уже вызвала бы ошибку.

Если вы хотите получить доступ к первому энтерн-интерфейсу из приложения UDP в том же узле, вы должны использовать относительный путь, что-то вроде этого: ^.eth[0].mac.queue

Наконец, если вы не уверены, правильно ли работает ваша модель, почему бы не запустить модель с Qtenv и проверить, получает ли данный модуль какие-либо пакеты? Например, разверните модель до тех пор, пока данная очередь не откроется как простой модуль (т. е. вы увидите пустое пространство внутри модуля очереди), а затем коснитесь запустить/быстро запустить до следующего события в этом модуле. Если симуляция не останавливается, то этот модуль действительно не получил никаких пакетов и ваша конфигурация неверна.

person Rudi    schedule 25.01.2021
comment
Я отредактировал код, так логичнее, но все равно получил 0. Итак, я проанализировал симуляцию в среде Qtenv и увидел, что пакеты, приходящие на нужный ethernet-интерфейс, тут же запихиваются в очередь и выталкиваются из нее. Думаю, ничего страшного, очередь действительно всегда. Чтобы создать насыщение в буфере маршрутизатора, я должен увеличить данные, которые я отправляю на маршрутизатор, и/или уменьшить скорость передачи данных каналов? Или есть другие настройки, которые лучше подходят для этого? - person SuperFluo; 25.01.2021
comment
Действительно, вы должны увеличить приложение во всем по сравнению с лимитом мощности. Другого способа заполнить очереди нет. - person Rudi; 25.01.2021
comment
Эй, я отредактировал значение параметров в .ini файле, но теперь, через 50 секунд, я получаю это сообщение: Возврат неполного чанка не разрешен согласно флагам: 1 -- в модуле (inet::TcpGenericServerApp) Network .server.app[1] ... Я думаю, мне следует уменьшить количество отправляемых данных, но если я это сделаю, я не смогу создать насыщение в буфере. - person SuperFluo; 25.01.2021