Difference between revisions of "Object Start Stop specification"

From Nsnam
Jump to: navigation, search
(Intial version of the specification)
 
(Object::IsActive())
Line 9: Line 9:
 
* For member variables (including attributes), there is no automation; the subclass must '''explicitly''' decide what to do with its members.
 
* For member variables (including attributes), there is no automation; the subclass must '''explicitly''' decide what to do with its members.
 
* It should be possible for a NetDevice to asynchronously learn of a stopped Channel, depending on the needs of the model.
 
* It should be possible for a NetDevice to asynchronously learn of a stopped Channel, depending on the needs of the model.
 +
** It would be better if we wanted something more general, i.e. it should be possible to query the status of any Object with Object::IsActive() or a similar metod. [[User:Vedranm|Vedran Miletić]]
  
 
=== Under discussion ===
 
=== Under discussion ===

Revision as of 11:02, 22 September 2012

Note: Initial specification taken mostly from here: http://mailman.isi.edu/pipermail/ns-developers/2012-September/010658.html

Features

Mostly agreed upon

  • Object::Start and Object::Stop each can be called multiple times (no need for separate Reset).
    • If Object::Start is called on a started object, it will perform an implicit Stop() then Start().
    • If Object::Stop () is called on a stopped object, it is a no-op.
  • For both Start and Stop, an Object subclass will call the corresponding method on all of its aggregates, and call up to the parent class.
  • For member variables (including attributes), there is no automation; the subclass must explicitly decide what to do with its members.
  • It should be possible for a NetDevice to asynchronously learn of a stopped Channel, depending on the needs of the model.
    • It would be better if we wanted something more general, i.e. it should be possible to query the status of any Object with Object::IsActive() or a similar metod. Vedran Miletić

Under discussion

  • Events are (are not?) removed from the scheduler pertaining to stopped objects.
    • Comment: I'm not sure how to decide what to remove and what not; object might be restarted and ready in time of a scheduled event, and I believe it depends on the kind of an object whether it should or should not process those events. Soft "are not" on this one; it should be up to the model to decide what object does or doesn't when stopped. Vedran Miletić
  • Stopped netdevices are (are not?) removed from the channel
    • Are not: stopped netdevices should be kept on the channel, just not Tx/Rx. Vedran Miletić

Example use cases

  • An energy model aggregated to a Node depletes all of its energy. It then stops itself, which (by virtue of aggregation) will call Node::Stop, which will stop everything on the node. If the energy model later obtains more energy, it could restart, which should restart the whole Node.
  • User calls Node::Stop() which stops all applications and NetDevices on the node, as well as any objects that have been aggregated to the node. User can later call Node::Start() to restart everything.
  • User calls NetDevice::Stop()/Start() which just manipulates that device and any objects associated to that device, but does not impact other devices or the Node itself.
  • User calls Channel::Stop() which causes channel to stop transmitting packets, and makes NetDevices able to find out about the channel status.