[Ns-developers] NetDevice::SetAddress

[craigdo@ee.washington.edu]

> NetDevice::SetAddress requires that the caller knows the 
> address format
> of the underlying NetDevice. This means that, as a caller, you have to
> know the exact type of the underlying NetDevice to construct 
> the needed
> Address object. 

No, not quite.  The SetAddress method takes any address, but only responds
favorably to Mac48Address.  So you need to know that the underlying
(bridged) NetDevice can understand a Mac48Address if you give it an Address
of that flavor.  You absolutely don't need to know what kind of NetDevice it
is.  That's the important point here.

> If this is the case, I don't understand why the caller
> can't just DynamicCast and call the appropriate SetAddress 
> method on the
> subclass.

It's not the case.  

The whole point of the SetAddress method was so that a tap-bridge wouldn't
have to figure out that it needed to call csma->SetAddress() in one case and
wifi->m_mac->SetAddress() or pointToPoint->SetAddress() in another or
yadda->SomeEntirelyDifferentThing() in a future unknown net device.

If a user bridges together devices that both use Mac48Addresses, it works.
If the user tries to USE_LOCAL bridge together non-matching address types it
fails.  This is what I would expect.

> i.e., I am concerned that, so far, the NetDevice API was designed to
> make it possible for a caller to ignore the underlying 
> address format to
> call any method defined in this class and SetAddress is breaking this
> design assumption. The methods we currently have which take an Address
> as argument are expected to pass an address coming from somewhere else
> so, until now, we never had to know the address format of an 
> underlying
> device to call any method defined in the NetDevice base class. 

In order to make the tap-bridge work in a VM environment, we have to change
one of two MAC addresses.  The MAC address of the VM device can't be
changed, so we get to change the MAC address of the ns-3 net device if we
want to support bridging non-sta wifi devices when promiscuous mode won't
work (as discussed on the list some time ago).

We don't want to teach the tap bridge about every possible net device type
(so it can appropriately cast and use some subclass method), so we get to
use a NetDevice base class method and the tap-bridge uses Ptr<NetDevice>
only.

The question is then, do we want to use a Mac48Address base class method or
an Address method?  The answer seems obviously Address since we don't want
the NetDevice base class tied to a particular address type.  Thus there is a
SetAddress method added to the NetDevice base class.

The Address in question is really passed from another place as you suggest
-- it isn't made up out of whole cloth, it comes from another device using a
Mac48Address.  In the past, Address parameters "coming from somewhere else"
needed to be understandable by a given net device.  This was true for Send,
for example.  You can't just call Send on a CSMA device with a random
Address from Mars, it must really be a Mac48Address.  This is still the
case.  You can't call SetAddress with a random address from Mars, it must
really be a Mac48Address.

I don't see the problem.  It seems quite straightforward to me.

-- Craig