Tracing on IPv4L3

[HA]

Hi,

I am trying to connect the trace source Rx in class Ipv4L3Protocol to the IPv4ReceivedPackets function, before starting the simulator as following:

uint32_t mIPv4ReceivedPackets = 0;

void IPv4ReceivedPackets(const Ptr< const Packet > packet, const Ptr< const Ipv4 > ipv4, const uint32_t interface)

{

    mIPv4ReceivedPackets++;

}

Config::ConnectWithoutContext("/NodeList/*/$ns3::Ipv4L3Protocol/Rx" , MakeCallback(&IPv4ReceivedPackets));

However, when I run the simulator it aborts the simulation and reports the following error, from which it seems that the trace path I specified does not exist

Program received signal SIGSEGV, Segmentation fault.

0x00007ffff74dabc3 in ns3::Callback<void, ns3::Ptr<ns3::Packet const>, ns3::Ptr<ns3::Ipv4>, unsigned int, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty>::DoAssign (

    this=0x7fffffffb640, other=...) at ./ns3/callback.h:1256

1256        NS_FATAL_ERROR ("Incompatible types. (feed to \"c++filt -t\" if needed)" << std::endl <<

(gdb) bt

#0  0x00007ffff74dabc3 in ns3::Callback<void, ns3::Ptr<ns3::Packet const>, ns3::Ptr<ns3::Ipv4>, unsigned int, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty>::DoAssign (

    this=0x7fffffffb640, other=...) at ./ns3/callback.h:1256

#1  0x00007ffff74d9196 in ns3::Callback<void, ns3::Ptr<ns3::Packet const>, ns3::Ptr<ns3::Ipv4>, unsigned int, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty>::Assign (

    this=0x7fffffffb640, other=...) at ./ns3/callback.h:1220

#2  0x00007ffff74d83f4 in ns3::TracedCallback<ns3::Ptr<ns3::Packet const>, ns3::Ptr<ns3::Ipv4>, unsigned int, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty>::ConnectWithoutContext (

    this=0x6b6c38, callback=...) at ./ns3/traced-callback.h:267

#3  0x00007ffff74c7b70 in ns3::Accessor::ConnectWithoutContext (this=0x684be0, obj=0x6b6b70, cb=...) at ./ns3/trace-source-accessor.h:148

#4  0x00007ffff50c9255 in ns3::ObjectBase::TraceConnectWithoutContext (this=0x6b6b70, name=..., cb=...) at ../src/core/model/object-base.cc:307

#5  0x00007ffff511b5e3 in ns3::Config::MatchContainer::ConnectWithoutContext (this=0x7fffffffb820, name=..., cb=...) at ../src/core/model/config.cc:123

#6  0x00007ffff5121963 in ns3::ConfigImpl::ConnectWithoutContext (this=0x7ffff53aa0a0, path=..., cb=...) at ../src/core/model/config.cc:557

#7  0x00007ffff5124191 in ns3::Config::ConnectWithoutContext (path=..., cb=...) at ../src/core/model/config.cc:736

I tried to connect the trace source after running the simulation by encapsulating the ConnectWithoutContext in a user function and schedule it after certain time (To have the Internet Stack Object Created) but I get the same result. So what is the source of the problem? 

Thanks a lot.

[Konstantinos]

Hi,

There seems to be a documentation error (that's why I CC'd P. Barnes)

The trace source for Rx packets is defined as:

TracedCallback<Ptr<const Packet>, Ptr<Ipv4>, uint32_t> ns3::Ipv4L3Protocol::m_rxTrace

but the link to the trace source gives this (https://www.nsnam.org/doxygen/classns3_1_1_ipv4_l3_protocol.html#a860636cccfbf605fcb77c65d0a2d75f4)

typedef void(* ns3::Ipv4L3Protocol::TxRxTracedCallback) (const Ptr< const Packet > packet, const Ptr< const Ipv4 > ipv4, const uint32_t interface)

setting the Ipv4 object as 'const' which is not the case. 

If in your script you change the function signature as follows the error is fixed

void IPv4ReceivedPackets(const Ptr< const Packet > packet, Ptr<Ipv4 > ipv4, const uint32_t interface)
{
    mIPv4ReceivedPackets++;
}

Regards,

K

[HA]

Thanks Konstantios, problem solved

[Barnes, Peter D.]

[cc’ing the developers list for discussion]

Thanks Konstantinos. Indeed, the class member and callback function signature differ.

When I added the TracedCallback signature typedefs I assumed that TracedCallbacks shouldn’t modify the data being traced, so I const’ed everything in the typedefs. Rationale: if tracing can modify the state of simulation objects, the results of simulations will depend on *what* traces are hooked, which seems to me to be in Mathieu’s “bad idea (tm)” category.

On looking at this again, I can imagine that a trace sink might want to cache things like packets, or Ipv4 instances, etc. If we want to allow these, I suggest we adopt these two rules for TracedCallback arguments:

1. All arguments are const, with the exception of

2. Ptr’s themselves (so sinks can cache the Ptr, which will increment the ref count)

So, for this example, the typedef should be:

typedef void (* TxRxTracedCallback)
(/* non-const */ Ptr<const Packet> packet,
/* non-const */ Ptr<const Ipv4> ipv4,
const uint32_t interface);

As an alternative to rule 2, we could consider making SimpleRefCount<T>::m_count mutable, but I don’t know what other implications that would have.

Thoughts?
Peter

> On Jun 25, 2015, at 9:20 AM, Konstantinos <dinos.k...@gmail.com> wrote:
>
> Hi,
>
> There seems to be a documentation error (that's why I CC'd P. Barnes)
>
> The trace source for Rx packets is defined as:
> TracedCallback<Ptr<const Packet>, Ptr<Ipv4>, uint32_t>
> ns3::Ipv4L3Protocol::m_rxTrace
>
> but the link to the trace source gives this (https://www.nsnam.org/doxygen/classns3_1_1_ipv4_l3_protocol.html#a860636cccfbf605fcb77c65d0a2d75f4)
>
> typedef void(* ns3::Ipv4L3Protocol::TxRxTracedCallback) (
> const Ptr< const Packet > packet,
> const Ptr< const Ipv4 > ipv4,
> const uint32_t interface)
>
> setting the Ipv4 object as 'const' which is not the case.
>

> Regards,
> K
>
>
> On Thursday, June 25, 2015 at 4:33:36 PM UTC+1, HA wrote:
>> Hi,
>>
>> I am trying to connect the trace source Rx in class Ipv4L3Protocol to the IPv4ReceivedPackets function, before starting the simulator as following:
>>
>> uint32_t mIPv4ReceivedPackets = 0;
>>
>> void IPv4ReceivedPackets(const Ptr< const Packet > packet, const Ptr< const Ipv4 > ipv4, const uint32_t interface)
>> {
>> mIPv4ReceivedPackets++;
>> }
>>
>> Config::ConnectWithoutContext("/NodeList/*/$ns3::Ipv4L3Protocol/Rx" , MakeCallback(&IPv4ReceivedPackets));
>>
>> However, when I run the simulator it aborts the simulation and reports the following error, from which it seems that the trace path I specified does not exist

_______________________________________________________________________
Dr. Peter D. Barnes, Jr. Physics Division
Lawrence Livermore National Laboratory Physical and Life Sciences
7000 East Avenue, L-50 email: pdba...@llnl.gov
P. O. Box 808 Voice: (925) 422-3384
Livermore, California 94550 Fax: (925) 423-3371

[Tom Henderson]

On 06/26/2015 11:13 AM, Barnes, Peter D. wrote:
> [cc’ing the developers list for discussion]
>
> Thanks Konstantinos. Indeed, the class member and callback function
> signature differ.
>
> When I added the TracedCallback signature typedefs I assumed that
> TracedCallbacks shouldn’t modify the data being traced, so I const’ed
> everything in the typedefs. Rationale: if tracing can modify the
> state of simulation objects, the results of simulations will depend
> on *what* traces are hooked, which seems to me to be in Mathieu’s
> “bad idea (tm)” category.

I think that this assumes that traces are the only thing that should be
hooked to traced callbacks, but it seems to me that TracedCallbacks are
just a list of Callbacks and aren't necessarily restricted to passive
tracing operations. If so, I would suggest that adding constness should
just be a local policy decision of the trace source author.

- Tom

[Barnes, Peter D.]

Hmm. Do we have an example of TracedCallbacks being used this way? AFAI remember, when we have Callbacks the class typically also has a SetXCallback function, so it’s explicit in code how the model is assembled. Since TracedCallbacks can be connected from Config, command line, etc, it’s no longer explicitly what model is actually running.

Knowing how erratic our const-correctness is, I don’t think we can count on authors to have thought this through.

Peter

[Vedran Miletić]

2015-06-26 22:31 GMT+02:00 Barnes, Peter D. <barn...@llnl.gov>:

> On Jun 26, 2015, at 11:59 AM, Tom Henderson <to...@tomh.org> wrote:
> On 06/26/2015 11:13 AM, Barnes, Peter D. wrote:
>> [cc’ing the developers list for discussion]
>>
>> Thanks Konstantinos.  Indeed, the class member and callback function
>> signature differ.
>>
>> When I added the TracedCallback signature typedefs I assumed that
>> TracedCallbacks shouldn’t modify the data being traced, so I const’ed
>> everything in the typedefs.  Rationale:  if tracing can modify the
>> state of simulation objects, the results of simulations will depend
>> on *what* traces are hooked, which seems to me to be in Mathieu’s
>> “bad idea (tm)” category.
>
> I think that this assumes that traces are the only thing that should be hooked to traced callbacks, but it seems to me that TracedCallbacks are just a list of Callbacks and aren't necessarily restricted to passive tracing operations.  If so, I would suggest that adding constness should just be a local policy decision of the trace source author.

Hmm.  Do we have an example of TracedCallbacks being used this way?  AFAI remember, when we have Callbacks the class typically also has a SetXCallback function, so it’s explicit in code how the model is assembled.  Since TracedCallbacks can be connected from Config, command line, etc, it’s no longer explicitly what model is actually running.

Knowing how erratic our const-correctness is, I don’t think we can count on authors to have thought this through.

I agree on this part.

With regard to Ptr<> being non-const, two things:
1) Isn't m_count already mutable? Line 142 in simple-ref-count.h is:

  mutable uint32_t m_count;

2) Is Ptr<> the only case where where modifications make sense in tracing? I can't think of anything else, but before making decision on this of either kind we should make sure Ptr<> is the only exception.

Regards,

Vedran

--

Vedran Miletić
http://vedranmileti.ch/

[Natale Patriciello]

On 29/06/15 at 11:58pm, Vedran Miletić wrote:
> > > On Jun 26, 2015, at 11:59 AM, Tom Henderson <to...@tomh.org> wrote:
> > Hmm. Do we have an example of TracedCallbacks being used this way? AFAI
> > remember, when we have Callbacks the class typically also has a
> > SetXCallback function, so it’s explicit in code how the model is
> > assembled. Since TracedCallbacks can be connected from Config, command
> > line, etc, it’s no longer explicitly what model is actually running.
> >
> > Knowing how erratic our const-correctness is, I don’t think we can count
> > on authors to have thought this through.
> >
>
> I agree on this part.

In principle, I agree with Peter: I have seen TracedCallback only as a
way to "see" values (like a footprint). However, sometimes I miss a way
to "connect" many functions to particular event. This is exactly the
application of Callbacks, but for what I know the Callback have the
limitation that only one method can be connected.

So, why not introduce a new concept, similar to Qt (and c++11 I think)
"signal" ? The major feature would be the possibility to attach many
functions, each one can modify the arguments (passed by Ptr<> or
reference).

Callback -> Interconnect ns-3 modules and protocols, signature
developer-defined

TracedCallback -> Used by users to trace values inside simulator (all
const)

signals -> Emitted by ns-3 modules and protocols during their
functionalities, can be "connected" by users and developers to
alter/check the code functionality. Signature developer-defined.


What do you think ?

Nat

[Ankith Rao]

Hi,

I am trying to use the above mentioned function for a callback in the csma-ping.cc file. But the callback is not getting triggered. Attached is a copy of the code.
Can anyone please help.

Thanks in advance.

[Tommaso Pecorella]

Hi,

it seems that your mistake is "only" due to bad copy-pasting. Please try to understand your code...

1) The Connect to Ipv4L3Protocol/Rx is made after Simulation::Run. Not a good idea.

2) The function you're trying to connect the callback to has a wrong signature (it needs a const Packet pointer)

3) $ns3::Ipv4L3Protocol/Rx is not a callback of an application !

Last but not least, read the posting guidelines and don't add private e-mail cc's unless strictly necessary.

T.