[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