Why copy message between helics applications?

[jaredd]

I have been reviewing HELICS as a potential enabler for some large scale ns-3 sims. Going through the sample applications I noticed that the HelicsApplication seemingly copies the message from the source application to the sink application (from the NS-3 perspective) while also sending the same message as a packet through the simulation. Did I misread the code? Is this intentional? If the simulation loses the packet (due to a lossy medium) does the Helics message map grow without bound?

[nightlark]

I think moving the received HELICS message from the source app to the sink app is intentional, with just the message data getting sent using an ns-3 packet (I seem to recall some discussion about this; the other approach is serializing the entire HELICS message struct and sending it as an ns-3 packet, which would make the simulated ns-3 packets larger).

I checked out the code, pretty sure you're right about the losing packets case -- it looks like the moved HELICS message will never get removed because the packet with the matching tag never arrives.

A co-worker suggested that https://www.nsnam.org/docs/tutorial/html/tracing.html could be used to get a callback on dropped packets (PhyRxDrop) that could be used to remove the dropped message from the sink app. I'm not sure when I'll have time to work on this, but if you fix it (or have other improvements) I'll get the PRs merged.

[jaredd]

There are a number of places that can drop a message depending on the underlying link. Just look through the wifi mac stuff. I wouldn't count on the PhyRxDrop (for which Phy?) to cover your bases. You guys already have a tag, why not incorporate the helics-specific metadata in that tag?

I can also imagine the case of a broadcast / multicast packet that get to only certain nodes and not others. This odd side-channel I imagine has many unintended affects. That tag would be replicated to all receivers too.

[nightlark]

It looks like adding the information to a tag would work. I don't see any reason why it couldn't be changed -- it might have been from looking at outdated ns-3.10 docs that mention a 20 byte size limit for packet tags that led to using this side-channel.