Difference between revisions of "Object Start Stop specification"

From Nsnam
Jump to: navigation, search
(Object::IsActive())
(Some more useful stuff)
Line 6: Line 6:
 
** If Object::Start is called on a started object, it will perform an implicit Stop() then Start().
 
** 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.
 
** 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.  
+
** Note, though, that it is important to call Start (not Stop) from the right context. Right now, this is ensured by NodeListPriv::Add when a node is created which propagates to all Start methods. So, a user who wants to 'restart' a node should not call Node::Start directly. He should call ScheduleWithContext(Node::GetId(), &Node::Start).
 +
** Maybe we need to find a way to make this less error prone by defining a Node-specific Start/Stop methods and making it illegal for users to call
 +
directly the Start/Stop methods of other objects.
 +
* 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.
 +
**  A question here is whether or not you should Stop a Channel if you Stop one of the attached NetDevices. ''Mathieu Lacage''
 +
*** '''No'': Doesn't make much sense to do it in general, IMHO it should be model-dependant. [[User:Vedranm|Vedran Miletić]]
 
* 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ć]]
 
** 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ć]]
 +
** What is a 'stopped' channel? ''Mathieu Lacage''
  
 
=== Under discussion ===
 
=== Under discussion ===
 
* Events are (are not?) removed from the scheduler pertaining to stopped objects.
 
* 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. [[User:Vedranm|Vedran Miletić]]
 
** '''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. [[User:Vedranm|Vedran Miletić]]
 +
** '''Are not''': not automatically. I would say that it is the responsability of each simulation object to cancel (or not) relevant events upon Stop in its DoStop method. ''Mathieu Lacage''
 
* Stopped netdevices are (are not?) removed from the channel
 
* Stopped netdevices are (are not?) removed from the channel
 
** '''Are not''': stopped netdevices should be kept on the channel, just not Tx/Rx. [[User:Vedranm|Vedran Miletić]]
 
** '''Are not''': stopped netdevices should be kept on the channel, just not Tx/Rx. [[User:Vedranm|Vedran Miletić]]
 +
** '''Are not''': It seems a lot of work to make sure that all NetDevice objects do this properly.
  
 
== Example use cases ==
 
== 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.
 
* 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.
 +
** If it does this, it needs to be careful to call ScheduleWithContext for the restart. ''Mathieu Lacage''
 
* 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 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.
 +
** It seems to me from this discussion that there are 3 kinds of objects on which users might be tempted to call Stop or Start: Node, NetDevice, Channel, and maybe Application? All other objects should _never_ receive a call to Start or Stop
 +
directly by a user. Now, the question is: what are the expected user-visible semantics of calling Start/Stop on each of these objects? ''Mathieu Lacage''
 
* 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 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.
 
* User calls Channel::Stop() which causes channel to stop transmitting packets, and makes NetDevices able to find out about the channel status.

Revision as of 16:30, 7 October 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.
    • Note, though, that it is important to call Start (not Stop) from the right context. Right now, this is ensured by NodeListPriv::Add when a node is created which propagates to all Start methods. So, a user who wants to 'restart' a node should not call Node::Start directly. He should call ScheduleWithContext(Node::GetId(), &Node::Start).
    • Maybe we need to find a way to make this less error prone by defining a Node-specific Start/Stop methods and making it illegal for users to call

directly the Start/Stop methods of other objects.

  • 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.
    • A question here is whether or not you should Stop a Channel if you Stop one of the attached NetDevices. Mathieu Lacage
      • 'No: Doesn't make much sense to do it in general, IMHO it should be model-dependant. Vedran Miletić
  • 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ć
    • What is a 'stopped' channel? Mathieu Lacage

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ć
    • Are not: not automatically. I would say that it is the responsability of each simulation object to cancel (or not) relevant events upon Stop in its DoStop method. Mathieu Lacage
  • 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ć
    • Are not: It seems a lot of work to make sure that all NetDevice objects do this properly.

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.
    • If it does this, it needs to be careful to call ScheduleWithContext for the restart. Mathieu Lacage
  • 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.
    • It seems to me from this discussion that there are 3 kinds of objects on which users might be tempted to call Stop or Start: Node, NetDevice, Channel, and maybe Application? All other objects should _never_ receive a call to Start or Stop

directly by a user. Now, the question is: what are the expected user-visible semantics of calling Start/Stop on each of these objects? Mathieu Lacage

  • 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.