[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ns] Hierarchical addressing and mcast



----- Original Message -----
From: "John Heidemann" <[email protected]>
To: "B. Scott Michel" <[email protected]>
Cc: <[email protected]>
Sent: Thursday, October 19, 2000 5:02 PM
Subject: Re: [ns] Hierarchical addressing and mcast


> There are parts of ns that don't work together, often because
> interactions between routing and the rest of the code.  We hope to
> take another whack at routing with cleaner APIs in the next six months
> or so.  Of course we're willing to accept patches to fix problems.
> Unfortunately, given a choice between making sure ALL n x n features
> work together and insuring that basic features work in basic
> scenarios, the choice is often for the later.

Fundamentally, in all well-designed and maintained software, there are a set
of "critical" features that work together. While you and I may disagree what
those features are as a total set, I'd have to say that hierarchical
addressing is one of them and it is fairly fundamental to the operation of
network routing protocols as we know them today.

Once a "critical" or "core" set of features are eventually specified, it
will eventually be incumbent on those who extend or add to this simulator to
make sure that they support and interoperate correctly with those features.
If LANs are a core feature, it's incumbent on the mcast routing
people/maintainer(s) to make sure they support LANs.

Actually, it would do the community at large some good to say what parts of
ns are "core features" so that the community can peg its expectations.

I only say this because ns is a good piece of software (mostly... :-) but it
needs some work before it becomes a GREAT piece of software. I'm happy I'm
not reinventing the wheel like I would with other simulation packages. ns is
one of the few sims that actually decided to use a scripting language (as
good or bad as Tcl happens to be) as a configuration language. You don't see
this with other (open source) simulation packages. However, I do think ns
needs some software engineering done to it, such as what Jon and students
are doing with the Java version. Unfortunately, it'll be interesting to see
what config language they come up with (or see them create a Tcl interpreter
with Java...).

> (The alternative is to not including a feature until it works well
> with everything.  In practice, this really means never adding new
> features, so you can see why we take a different path.  I can
> understand why it's frustrating for users... although given some of
> the contributed code it seems like everyone adopts this policy :-)

Software engineering is actually a good thing.... and yes, policy applied
properly can also be a good thing too.

And yes, I'll send the dmalloc patches in the near future to the list. I'll
need to merge 2.1b7 before I do, as a first order of business. And if I'm
properly motivated, I might look into why hierarchical addressing doesn't
work for some of the mcast routing protocols.

Is there a wishlist somewhere?

-scooter