[Ns-developers] Requesting help for csma promiscuous mode

[Gustavo Carneiro]

2008/7/5 Tom Henderson <tomh at tomh.org>:

> craigdo at ee.washington.edu wrote:
>
>
>> I want to point out that we seem to be operating in a mode where API
>> changes
>> are a non-issue.  That surprises me.
>>
>
>
> It is not a non-issue, but at issue also is the long-term integrity of what
> we are building.  Now that we are past 3.1 release, we are going to be faced
> with questions like this repeatedly.
>
> I expect that in 3.2 release (and probably a few more), we will have to
> have release notes that call out a few changes; e.g.
>
> "API changes from 3.1 to 3.2
> ============================
> 1. CsmaChannel::Send(); now takes an extra NetDevice parameter
> 2. ...
> "
>
> I would hope that this would decline in frequency with each release, as we
> get more and more usage.
>
> I think the API stability we want in this project is stability that, first
> of all, doesn't cause subtle undetected errors when using the API across
> simulator versions, and second, doesn't present a serious impediment to
> upgrading and usability.  If someone's build breaks but the fix is easy and
> well documented, that doesn't concern me too much at this stage of ns-3
> development.


I think that is a reasonable rule.  On that note:

  1- NetDevice callbacks have to change signature;

  2- Node protocol handlers have to change callback signature;

  3- Protocol handlers have to be prepared to ignore packets "not for me".
>From my experience looking at the code, figuring this out is far from
trivial (different address types, dealing with L2 multicast groups, etc.),
so the extra packet type parameter is needed if we want to keep developers'
mental sanity.

  4- I really think it makes no sense in NS-3 to have a "promiscuous mode"
if we have a single receive callback in netdevices.  Might as well _always_
receive in promiscuous mode because a) simplifies API, and b) allows subtle
bugs of a protocol handler not being prepared for promiscuous mode, due to a
bug, and suddenly another handler activates the promiscuous mode and
triggers a bug in the first handler, until then undiscovered.  "Modes" in
general are usually evil because of the way they attract bugs when multiple
independent code modules are brought together into the same system.

That means breaking the API :(  But ok, if it makes Mathieu happy, and at
least adapting to the new API wouldn't be so difficult.

I'm going to sketch these ideas now...

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert