[NS3]Why my applications do not stop?

[Harlan]

I run an example:

It is /ns-3.23/examples/matrix-topology/matrix-topology.cc The following are the time parameters:

double SimTime        = 3.00;//simulator stop time
double SinkStartTime  = 1.0001;
double SinkStopTime   = 2.90001;
double AppStartTime   = 2.0001;
double AppStopTime    = 2.80001;

And after that, the Stop function set the stopTime.

ApplicationContainer apps;
apps.Add(onoff.Install (nodes.Get (i)));  // traffic sources are installed on all nodes
apps.Start (Seconds (AppStartTime + rn));
apps.Stop (Seconds (AppStopTime));

But it didn't work.....In the ASCII tracing file, the "+", "-" and"r" exist until the the simulator stops. So my question is how to stop a application? It seems that it doesn't work. I checked the API document but I still do not know why.

Here is the last three lines of the ASCII tracing file:

r 2.99973 /NodeList/13/DeviceList/5/$ns3::PointToPointNetDevice/MacRx ns3::PppHeader (Point-to-Point Protocol: IP (0x0021)) ns3::Ipv4Header (tos 0x0 DSCP Default ECN Not-ECT ttl 64 id 0 protocol 17 offset (bytes) 0 flags [none] length: 540 10.0.0.121 > 10.0.0.14) ns3::UdpHeader (length: 520 49175 > 9) Payload (size=512)

+ 2.99973 /NodeList/13/DeviceList/5/$ns3::PointToPointNetDevice/TxQueue/Enqueue ns3::PppHeader (Point-to-Point Protocol: IP (0x0021)) ns3::Ipv4Header (tos 0x0 DSCP Default ECN Not-ECT ttl 64 id 0 protocol 1 offset (bytes) 0 flags [none] length: 56 10.0.0.122 > 10.0.0.121) ns3::Icmpv4Header (type=3, code=3) ns3::Icmpv4DestinationUnreachable (tos 0x0 DSCP Default ECN Not-ECT ttl 64 id 0 protocol 17 offset (bytes) 0 flags [none] length: 540 10.0.0.121 > 10.0.0.14 org data=192 23 0 9 2 8 0 0 )

- 2.99973 /NodeList/13/DeviceList/5/$ns3::PointToPointNetDevice/TxQueue/Dequeue ns3::PppHeader (Point-to-Point Protocol: IP (0x0021)) ns3::Ipv4Header (tos 0x0 DSCP Default ECN Not-ECT ttl 64 id 0 protocol 1 offset (bytes) 0 flags [none] length: 56 10.0.0.122 > 10.0.0.121) ns3::Icmpv4Header (type=3, code=3) ns3::Icmpv4DestinationUnreachable (tos 0x0 DSCP Default ECN Not-ECT ttl 64 id 0 protocol 17 offset (bytes) 0 flags [none] length: 540 10.0.0.121 > 10.0.0.14 org data=192 23 0 9 2 8 0 0 )

We can see that the first "r" line is later than SinkStopTime and "+" & "-" is later than AppStopTime.

Thank you!

[Tommaso Pecorella]

Hi,

the application IS stopped, but the data it did generate can live for some time in the simulator. This can be due to routing, congestion, channel access, etc. In this case you can see one packet is received after the application has been stopped (who knows when it was generated, probably much earlier) and one ICMP destination unreachable (the sink is already stopped, one shouldn't stop the receiver 0.1 seconds after the sender).

T.

[徐海亮]

Hi,

I modify the time parameters like this:

  double SimTime        = 4.00;

  double SinkStartTime  = 1.0001;

  double SinkStopTime   = 3.0001;

  double AppStartTime   = 2.0001;

  double AppStopTime    = 2.10001;

 And the last three lines of the tracing file is:

r 3.99998 /NodeList/1/DeviceList/2/$ns3::PointToPointNetDevice/MacRx ns3::PppHeader (Point-to-Point Protocol: IP (0x0021)) ns3::Ipv4Header (tos 0x0 DSCP Default ECN Not-ECT ttl 63 id 15 protocol 17 offset (bytes) 0 flags [none] length: 540 10.0.0.45 > 10.0.0.110) ns3::UdpHeader (length: 520 49162 > 9) Payload (size=512)

+ 3.99998 /NodeList/1/DeviceList/5/$ns3::PointToPointNetDevice/TxQueue/Enqueue ns3::PppHeader (Point-to-Point Protocol: IP (0x0021)) ns3::Ipv4Header (tos 0x0 DSCP Default ECN Not-ECT ttl 62 id 15 protocol 17 offset (bytes) 0 flags [none] length: 540 10.0.0.45 > 10.0.0.110) ns3::UdpHeader (length: 520 49162 > 9) Payload (size=512)

- 3.99998 /NodeList/1/DeviceList/5/$ns3::PointToPointNetDevice/TxQueue/Dequeue ns3::PppHeader (Point-to-Point Protocol: IP (0x0021)) ns3::Ipv4Header (tos 0x0 DSCP Default ECN Not-ECT ttl 62 id 15 protocol 17 offset (bytes) 0 flags [none] length: 540 10.0.0.45 > 10.0.0.110) ns3::UdpHeader (length: 520 49162 > 9) Payload (size=512)

I still don't know why. The application should stop in 2.1s. But in 3.99998s, there is still a packet sending out.

Also, the sink stops in 3s, I don't know why it can receive a packet in 3.99998s.

Thank you so much!! 

--
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/0LaaSbmHIU4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

--

徐海亮

132-6171-3001

harla...@gmail.com

北京邮电大学 计算机科学与技术 本科 大三

[Tommaso Pecorella]

Hi,

without the source code is hard to say. I can only suggest to add some debug lines (or use one of the many ns-3 debugging methods) to check when that packet was created and why it's sent at that time.

T.

[harlan]

Hi Tommaso,

Thank you for your kindness!!!

I have already found the fault. The stopTime is before the startTime! Because the parameter in ApplicationContainer.start(time) is not the AppStartTime……. It’s AppStartTime + a float number, which is bigger than the AppStopTime.

Again, thank you!