[Ns-bugs] [Bug 89] Not possible to free nodes before the end of a simulation

[bugzilla-daemon@nsnam-www.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=89





------- Comment #1 from mathieu.lacage at sophia.inria.fr  2007-12-26 09:57 -------
There are a lot of issues to consider here:

Implementation: the main issue to make it possible to free nodes before the end
of simulation is to allow a user to remove a node from the NodeList. The big
problem with such a change is that the index of a Node in a NodeList is also
the NodeId. The main reason behind this implementation detail is that we wanted
to make it really efficient to perform a lookup by node id in the NodeList.
This lookup is performed in the tracing code when it wants to know from which
node a trace event is coming from. Specifically, it is the ArrayTraceResolver
which is storing this nodeid as an index in a TraceContext.


While fixing bug 98, I spent a good while thinking about this implementation
issue. There are a lot of implementation options:
  - we could just mark freed nodes as zero in the NodeList and implement a new
NodeList iterator which would be able to skip of these zero entries.
  - we could attempt to store in the TraceContext a Ptr<Node> rather than a
node index, hence making the whole index problem go away.
  - ...

However, every implementation option I looked is somewhat non-trivial to
retrofit within the current codebase so, I am a bit worried that this is going
to be really painful to do and, my next question is: what is the expected
output ?

I can imagine lots of use-cases where, indeed, being able to create and destroy
nodes during the simulation could be useful. The crux of the problem is that
supporting properly such a scenario requires much more work than just dealing
with node ids and the NodeList. i.e., as soon as you start doing partial
destructions of the simulation topology, you need to make sure that the global
system stays in a valid state. The current codebase was really designed to
_not_ support partial tearoffs so, if you try to do it, you will have to work
around a lot of design bugs, and you will have to put together a lot of adhoc
hacks for your specific scenario.

So, to summarize, to go forward with this bug, I think that we need to have a
very clear plan of how we can achieve partial destruction of a network topology
in such a way that the system stays in a coherent state after the partial
destruction.

Examples of problematic use-cases:
  - global routing data structures need updates
  - what are the semantics of destroying a NetDevice connected to a Channel
with multiple other NetDevices ?
  - same question for a pair of NetDevice and a single Channel.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.