[Ns-developers] ns3::RandomVariable

[Gustavo Carneiro]

2009/3/16 Raj Bhattacharjea <raj.b at gatech.edu>

> 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:


I should point out that there is a fundamental difference between Ptr and
the RandomVariable classes.  With Ptr, when you copy a pointer variable the
original object is not copied.  With a RandomVariable variable, copying the
variable will trigger a under-the-hood copy of the underlying XxxImpl.
Mathieu, correct me if I'm wrong (possible :)

But perhaps the difference does not matter in this case.  After all, a
RandomVariable object is supposed to generate a series random numbers, and
they are supposed to be independent.  So it should not matter whether you
generate two random numbers from a single RandomVariable object or one
number from one RandomVariable A and another one from a RandomVariable B,
where B is a copy of A.


>
>
> 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.


Absolutely!  /me loves ns3/ptr.h :-)

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert