[Ns-developers] finalizing the ns-3 object model (configuration)
mathieu.lacage at sophia.inria.fr
Mon Jan 14 23:52:38 PST 2008
On Mon, 2008-01-14 at 20:22 -0800, craigdo at ee.washington.edu wrote:
> Parameters params;
> params.Set ("PointToPoint::ChannelDataRate", "5000000");
> params.Set ("PointToPoint::ChannelDelay", "2");
> Ptr<PointToPointChannel> channel0 =
> PointToPointTopology::AddPointToPointLink ( n0, n2, params);
The code above could be made to have the following syntax:
Ptr<PointToPointChannel> channel0 =
PointToPointTopology::AddPointToPointLink ( n0, n2, "name", value,
"name" value, ...);
which, I think, solves the problems you mention.
> Configuration subsystems are common and known by lots of people. Windows
> people know the registry. Apple devotees know the System Configuration
> Framework. Unix hackers understand .rc files. Thoroughly modern Linux
> major-generals can deal with GConf. There are lots of well-known and
> understood ways to configure complex systems. If you believe in the
> principle of least surprise, we should configure ns-3 with something that
> looks, at least conceptually, like everything else that configures systems.
> I was thinking about this last Friday and it occurred to me that the
> namespace in our tracing system gets us almost there. I have methods like
Yes. I have been pondering over this possibility too: part of the work
to get there would require that the tracing subsystem is integrated in
the TypeId stuff. It is on my TODO list.
> the following scribbled on my whiteboard:
> Set ("/nodes/*/tcp/reno/ssthresh", "16000");
> Set ("/nodes/1/tcp/rajno/cwnd". "4000");
I agree that this is a perfectly valid and desirable thing to do. I
think that it is perfectly implementable within the proposed TypeId
framework but I have yet to figure out a clean API to make it possible.
More information about the Ns-developers