[Ns-bugs] [Bug 822] NetDevice::Mtu attribute not settable by default

code@nsnam.ece.gatech.edu code at nsnam.ece.gatech.edu
Tue Apr 6 23:52:23 PDT 2010


http://www.nsnam.org/bugzilla/show_bug.cgi?id=822





--- Comment #8 from Mathieu Lacage <mathieu.lacage at sophia.inria.fr>  2010-04-07 02:52:23 EDT ---
(In reply to comment #5)
> 2) move this attribute to each subclass, but remove the device-specific frame
> size attributes so that we don't have two attributes pointing to one member
> variable (again leading to initialization order problems and user confusion)
>   pro:  MTU can be device specific (more realistic)
>   con:  breaks ns-3 API
> 
> 3) move Mtu attribute to each subclass, and decouple this attribute from the
> frame size attribute; these are two separate member variables.  This means that
> a user could e.g. set an Ethernet MTU of 1000 bytes even though the frame size
> was set to 1518 bytes.  Consistency checking would still be needed (that MTU <=
> (frame size - header size), for instance).
>   pro: preserves a device-specific MTU and preserves ns-3 API
>   con: still needs to be robust to initialization order issues; need to
> document to users that these concepts (FrameSize and Mtu) are still related in
> some way, but are not locked in-step to each other


The only robust way of doing this is 2). 3) is not workable because it
introduces dependencies between attributes. i.e., the result of a Set call will
depend on a earlier Set call. If each attribute is not independent from all
other attributes, this breaks many assumptions which in turn breaks code
attempting to perform generic serialization/deserialization of attributes. For
example ConfigStore will break in very subtle ways if we go with 3).

-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the Ns-bugs mailing list