[Ns-developers] NetDevice::SetAddress

[Mathieu Lacage]

On Sat, 2009-06-27 at 00:02 +0000, Tom Henderson wrote:

> I think I understand why you do not like this change, although not
> agreeing about being horribly wrong.  I thought about it some more

mathieu "horribly wrong" == tom "potentially problematic" :)

>  today and discussed it with Craig and still haven't seen what seems
> to be a better way.  There is perhaps a general danger of allowing
> users to change mac addresses after simulation start, but we do offer
> all of these SetAddress methods at the subclass level already, so that
> danger exists prior to this change.

I agree. I am more concerned about the need for the SetAddress
implementation to check for the type of the input address though. The
old dreaded "double dispatch" design problem. (my main argument against
SetChannel)
> 
> The problems that I see in initializing the underlying address to the
> right value in the first place are that there is no existing framework
> in place to pass these learned mac addresses (there may be dozens of
> them) into the ns-3 program and have them get associated to the right
> devices.  Plus, how to learn them from outside the containers?  In
> addition, it may impose a new requirement that ns-3 be started after
> the containers.

My feeling is that a lot of the work of configuring a linux host to be
able to talk to ns-3 through its ip stack does not belong to ns-3 and
should instead belong to external setup scripts. Creating the relevant
devices, getting their mac address, and giving them to ns-3 feels more
appropriate than asking ns-3 to do all of this.

What is painful right now is that there is no integrated solution to
implement these external setup scripts and to make them communicate with
ns-3. 
> 
> >Anyway, it's clearly
> >not something I can invest a lot of time thinking about now, a couple
> of
> >days before the release so, I am not going to push for a change there
> >right now.
> 
> If you are concerned about exposure of this API, what about making
> this a protected member of NetDevice and making the TapBridge a
> friend?  

I think that if we want to kill this API later, we can do so. Whether it
is private, protected or public is just the same: we have already broken
our API stability promise a couple of times. Once more won't make me
sleepless.

At this point, I am more concerned about trying to minimize churn within
our codebase for the release so, I would like to suggest that we bury my
concerns under a couple thousand pounds of concrete and try to make sure
I don't raise them again too soon. I will try :)

Mathieu