|
Bugzilla – Full Text Bug Listing |
| Summary: | v4Ping verbose output when not explicitly stopped | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Tom Henderson <tomh> |
| Component: | applications | Assignee: | Tommaso Pecorella <tommaso.pecorella> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | ns-bugs, tommaso.pecorella |
| Priority: | P5 | ||
| Version: | ns-3-dev | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | patch | ||
Created attachment 2369 [details]
patch
It turns out that Chris's suggestion was just right.
changeset: 12123:3b05558ad183 |
Chris Kosecki suggested to me off list that v4Ping only outputs the summary statistics if verbose is enabled and stoptime < simulator stoptime (or the application stop time is set to expire before simulator stop. The summary output is tied to StopApplication() which is not automatically called. At minimum, he suggests that this behavior is not mentioned anywhere, but has also suggested possibly using the v4Ping destructor to output this summary if the application had not been previously stopped. The pseudocode that he suggested was: NS_LOG_FUNCTION if m_next: StopApp // continue destructor We'd have to make small adjustments (e.g. StopApplication cannot assume m_socket is still valid) to permit this, but outside of those details, are there any opinions about these options: 1) just document the behavior; user is responsible for StopApplication() (which can be a problem if e.g. simulator is stopped from an external signal) 2) modify the destructor such as above 3) chain up to Simulation::Stop somehow (i.e. that Simulator::Stop should stop all nodes, which in turn stop all applications...) Regarding 3), Simulation::Stop() doing more than just stopping the scheduler and returning control to the main program is a broader topic that probably should be discussed when Object Stop/Start discussion is rekindled.