Difference between revisions of "Object Start Stop specification"

From Nsnam
Jump to: navigation, search
(Add outdated notice)
m (Vedranm moved page Object Start Stop Specification to Object Start Stop specification: specification should be lowercase)
(No difference)

Revision as of 12:42, 3 February 2013

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

Features

Note: this page is out of date at the moment. It will be updated as soon as possible.

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(). This breaks a lot of existing code. Better: If Object::Start() is called on a started object, it is a no-op.
    • 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.