Project

General

Profile

Task #4636

Modify docs to show producers unregistering prefixes to shut down faces

Added by Eric Newberry over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
Docs
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

Description

As discussed at the NDN Platform Call on June 11, the ndn-cxx documentation, including examples, needs to be modified so that producers are shown shutting down faces by unregistering all prefixes, instead of calling Face::shutdown(). This will ensure that the last sent Data packet is actually transmitted before the face shuts down.


Related issues

Related to ndn-cxx - Task #4642: Update producers across platform to unregister prefixes instead of shutting down faceClosedEric Newberry

Actions
#1

Updated by Eric Newberry over 2 years ago

  • Related to Task #4642: Update producers across platform to unregister prefixes instead of shutting down face added
#2

Updated by Eric Newberry over 2 years ago

  • Priority changed from Normal to High
#3

Updated by Eric Newberry over 2 years ago

The existing producer example in ndn-cxx doesn't shut down its face, except in response to a prefix registration error, where Face::unsetInterestFilter() would be of no use. Does it need to be modified at all?

Also, I can't find any specific references to Face::shutdown() in the ndn-cxx documentation. Even so, we should probably add something about the proper way to shut down a face on a producer.

#4

Updated by Davide Pesavento over 2 years ago

Eric Newberry wrote:

Also, I can't find any specific references to Face::shutdown() in the ndn-cxx documentation.

You mean besides the doxygen[1]? What other doc do we have?
[1] http://named-data.net/doc/ndn-cxx/current/doxygen/d9/d55/classndn_1_1Face.html#a94cece651790f2b3e140ed157667587e

Even so, we should probably add something about the proper way to shut down a face on a producer.

Yes, we should.

#5

Updated by Eric Newberry over 2 years ago

  • Status changed from New to Code review
  • % Done changed from 0 to 100
#6

Updated by Junxiao Shi over 2 years ago

“Waiting for processEvents() to exit” isn’t a proper solution when multiple faces are tied to the same io_service. Is there another way?
I’m suspecting the m_transport.close() line in Face::asyncShutdown(). StreamTransportImpl::close() clears the transmission queue, and packets could be lost there.

#7

Updated by Eric Newberry over 2 years ago

Junxiao Shi wrote:

“Waiting for processEvents() to exit” isn’t a proper solution when multiple faces are tied to the same io_service. Is there another way?
I’m suspecting the m_transport.close() line in Face::asyncShutdown(). StreamTransportImpl::close() clears the transmission queue, and packets could be lost there.

So do we need to modify the code to prevent this issue, instead of just shifting to unsetInterestFilter?

#8

Updated by Eric Newberry over 2 years ago

  • Status changed from Code review to Closed

The relevant change was merged.

@Junxiao, feel free to move this to "Feedback" if you think more discussion of note 6 is warranted.

#9

Updated by Davide Pesavento over 2 years ago

Junxiao Shi wrote:

“Waiting for processEvents() to exit” isn’t a proper solution when multiple faces are tied to the same io_service.

Is there a use case for employing multiple Face instances in the same application? If an application really wants to do what you're saying, it should call run()/stop()/reset()/etc.. on the io_service directly, and not use Face::processEvents() and shutdown().

Also available in: Atom PDF