[Ns-developers] ns3::RandomVariable

[Raj Bhattacharjea]

I am moving the discussion onto the developer's list, so please "reply
all" for further correspondence.  See my comments inline below.

On Thu, Mar 12, 2009 at 9:41 AM, Pascal Kesseli <pascal.kesseli at hsr.ch> wrote:
> Dear Mr Bhattacharjea
>
>
>
> Currently, we are developing a RTP traffic generator for NS3 as our
> bachelor’s thesis. While programming, we encountered the issue that some
> classes, e.g. ns3::RandomVariable, are not derived from ns3::Object. Thus,
> they cannot be used with ns3::Ptr, as the required Ref- and Unref-methods

The current design does something like what ns3::Ptr does, just "under
the covers" and without using Ptr objects.  Let me try and explain:

There are the publicly visible RandomVariable subclasses which you
know and interact with regularly to get numbers from a certain
distribution.  If you look at the code however, you will see that
these classes are just wrappers for underlying "Impl" classes.  That
is, e.g. UniformVariable forwards its relevant calls to
UniformVariableImpl.  The wrapper class, in addition to forwarding
calls, knows how to copy the underlying Impl, so that the user
experiences value semantics.  This was done so that anonymous
temporary RandomVariables could be passed around as parameters:

DoSomething(UniformVariable(1,3));

In summary, the user visible classes, i.e. RandomVariable subclasses,
are in some sense pointers that manage an underlying Impl.

> are not present. Doing so would be necessary for our project, as we want our
> traffic generator to be configured with various RandomVariable parameters,
> preferably passed as ns3::Ptr references (and stored polymorphically in an
> ns3::Ptr<RandomVariable> reference).

The classes in fact already have polymorphic semantics, just without
the explicit "Ptr":

RandomVariable x = UniformVariable(1,2);
RandomVariable y = ParetoVariable(...);
etc...

I know this looks weird (you may be wondering "where is the * or Ptr
on the LHS and the new or Create<> on the RHS"), but it is what we
have in ns-3, in the specific case of the RNGs.  Note that none of our
other classes really use these semantics.

The RandomVariable class is kind of a pointer already, able to hold
any of the Impl classes, and the whole effect provides this slightly
odd value semantic.

>
>
>
> Can you suggest a possible solution for this situation? And, by the way, how

You should be able to achieve exactly what you desire using ns-3
as-is; for an example of a traffic generator which takes
RandomVariable subclasses as parameters (without using Ptr), see the
OnOff application.  It achieves the effect by using the ns-3
attributes/TypeId system, but you could just as easily have methods
like:

MyApplication::SetRNG(RandomVariable x)

And then call this like:

Ptr<MyApplication> app;
RandomVariable ranvar = ExponentialVariable(10);
app->SetRNG(ranvar);


> do you feel about using third party (header-only) libraries, as e.g. Boost
> and its shared_ptr in such situations?
>

I think there was some discussion about using Boost or other
ready-made smart pointer solutions a long time ago.  Personally, I
think our Ptr solution keeps out an additional external build
dependency, and it is tailored to do exactly what we require in ns-3.

-- 
Raj Bhattacharjea
Georgia Institute of Technology
School of Electrical and Computer Engineering
Ph.D. Candidate
Systems Analyst
404.894.2955