[Ns-developers] Requesting help for csma promiscuous mode

[Gustavo Carneiro]

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

> 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.


*sigh*  I already implemented almost anything imaginable: dual rx callbacks
with preserving API compatibility, now implemented single rx callback with
breaking API.  Now, I don't mind going back to dual rx callbacks, but only
when I get unconditional approval, as it is time consuming to keep going
back and forth in the code.

Personally I think that my latest code breaks the API, but in a obvious way
and the extra PacketType parameter makes it clear that the handlers now my
receive extra packets, and also makes it easy for them to ignore the extra
packets.

But of course dual rx callbacks was always my gut feeling of how things
should be done...

Decisions, decisions... :-)

Thanks.

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