c++ - (OMNeT++) Where do packets go?

Question

I'm trying to do a project described also here: PacketQueue is 0

I've modified the UdpBasicApp.cc to suit my needs, and in the handleMessage() function I added a piece of code to retrieve the length of the ethernet queue of a router. However the value returned is always 0.

My .ned file regarding the queue of routers is this:

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

The code added in the UdpBasicApp.cc file is this:

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

So my question is this: is this the right way to create a queue in a router linked to other nodes with an ethernet link? My doubt is that maybe packets don't pass through the specified interface, i.e. I've set the ini parameters for the wrong queue.

question from:https://stackoverflow.com/questions/65885138/omnet-where-do-packets-go

Answer 1

You are not creating that queue. It was already instantiated by the OMNeT++ kernel. You are just getting a reference to an already existing module with the getModuleByPath() call.

The router3.eth[*].mac.queue. module path is rather suspicious in that call. It is hard-coded in all of your application to get the queue length from router3 even if the app is installed in router1. i.e. you are trying to look at the queue length in a completely different node. Then, the eth[*] is wrong. As a router obviously contains more than one ethernet interface (otherwise it would not be a router), you must explicitly specify which interface you want to sepcify. You must not specify patterns in module path (i.e. eth[0] or something like that, with an exact index must be specified). And at this point, you have to answer the question which ethernet interface I'm interested in, and specify that index. Finally the . end the end is also invalid, so I believe, your code never executes, otherwise the check_and_cast part would have raised an error already.

If you wanted to reach the first enthern interface from an UDP app in the same node, you would use relative path, something like this: ^.eth[0].mac.queue

Finally, if you are unsure whether your model works correctly, why not start the model with Qtenv, and check whether the given module receives any packet? Like,, drill down in the model until the given queue is opened as a simple module (i.e. you see the empty inside of the queue module) and then tap the run/fast run until next event in this module. If the simulation does not stop, then that module indeed did not received any packets and your configuration is wrong.