Object Start Stop specification

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.