[Ns-developers] Requesting help for csma promiscuous mode

[Tom Henderson]

Gustavo Carneiro wrote:
> 
> 
> 2008/7/5 Tom Henderson <tomh at tomh.org <mailto:tomh at tomh.org>>:
> 
>     craigdo at ee.washington.edu <mailto: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;
> 

ah, I see now.  I was wrong to previously suggest that it could be 
folded in without API breakage, because of this callback signature point.

>   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 think you are convincing me now to keep this handler separate, for all 
of the above reasons.

Tom