[Ns-developers] Parallelization Progress - Status Update

[Hagen Paul Pfeifer]

This email mainly concern some specialized parallelization topics, therefore
especially George. I will drop a more generic overview, status in ~2 days when
I push my work upstream.

Some words to the real node versus ghost node handling (For your information
George, currently there is no difference in the implementation, only to
differs generator nodes from non-generator nodes. To strip down the code is up
for further releases):

Beside the solution selected in GTNetS where the scenario files are
influenced with the parallelization aspect, NS-3 should does this in a
different way. For example: if a application is added to an node in GTNetS the
return value indicates if the node is a real or ghost node. My solution
selected for NS-3 differs in that way, that you can always add applications to
an node - no matter if this node is a real or ghost. The difference is under
the hood: NS-3 concern these calls as no-ops if it is a ghost and therefore is
fully transparent for the user. No matter if the simulation is parallelized or
not!  Thats my upcoming approach.

GTNetS indicator if a node is ghost is a method called AddApplication(). These
method returns NULL in the case that this node is a ghost, or an pointer in
the case that this node is a real one (scheduled on the local CPU).

There are two challenges in this sector:

First one is that NS-3 allows the user to add/implement their own application
by open a socket for a node and interact directly with lower API (e.g. the
IP/TCP stack implementation). So no uniform "AddApplication" interface is
available. This makes it harder to implement the mentioned feature, because
several places must be touched. To illustrate this: it is fully legal to open
an socket on a ghost node (just for fun), but it is illegal to open this
socket for an active interplay (e.g. to write to the socket). 

Another problem is the time where I calculate the federate distribution.
Currently this is done shortly before the simulation starts. If we want to add
a logic like GTNetS we must do this at the start of the main program. But the
user can call/execute whatever he want before call some ns-3 related methods.
Also, he can call the methods in arbitrary order. So express this in other
words: the scenario file can add applications to nodes who are ghosts-nodes
and the simulation does not even know this at time n that this is a ghost
node. So we must add a additional method so that the user can trigger the
federate calculation at the start of the simulation.  GNetS does this via
"Simualtor s(id);". My suggestion is to add a additional method to trigger the
process to calculate the federates!

The problem is that I don't want to mess with the core logic of NS-3. I want
to prevent major changes in API/Simulation/... But this is an unavoidable
influence where I need information guaranteed before the first couple of
lines (except parseArg()).

To summarize:

I prefer to add an additional method which must be called when run in a
parallelized context: lets call them "ParallelInit()". This is what I do
today. The federate splitting is done in a manner like GTNetS now handles
Ghost (extract from my current scenario file):

  if (federate->isLocalNode(n1n2.Get (1))) {

    PacketSinkHelper sink ("ns3::TcpSocketFactory",
        InetSocketAddress (Ipv4Address::GetAny (), servPort));
    ApplicationContainer apps = sink.Install (n1n2.Get (1));
    apps.Start (Seconds (0.0));

  }


This is *really* similar to the approach GTNetS is doing this. But I will
replace this with a more user transparent version soon as described in the
beginning of this email.

George, do you have some free IRC-time in the next couple of days to clarify
some open questions regarding time synchronization issues? No matter what time
- I will be there!  ;)


Hagen