[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:
>
>> craig really did not like it at all: he felt that was
>>> really completely weird to make the channel have this kind of logic.
>>>
>>
>> Yup.  I think this is almost a textbook example of a hack (as in a quick,
>> functionally correct, but problematic or hard to understand or maintain
>> change).
>>
>> What we're doing here is making the correct operation of a nicely
>> encapsulated network device object depend on a quite well-hidden behavior
>> of
>> another object -- the channel.  This strikes me as a bad practice from a
>> software engineering practice.  Someone could come along and wire in a
>> "better" channel and not implement the your packet filter since the
>> channel
>> has no reason to do such a thing, whence your code would break.  That is
>> bad.
>>
>> Also, when I think of a channel, I don't think of an entity that has any
>> kind of smarts to do packet filtering.  A CSMA channel is a wire, and the
>> wire should just deliver simulated EM signals.  I don't know of any wires
>> with processors built into them -- it's the devices that are attached to
>> the
>> wire that should figure out which signals on the wire to listen to.  So
>> from
>> an understandability perspective, I would not expect this functionality to
>> be in the channel at all.  It would surprise the heck out of me to be
>> debugging a problem and find this filtering in a "wire."
>>
>> There is a problem, though, in that we don't have a way to associate
>> signals
>> propagated through the medium with a transmitter except with packet
>> addressing information.  You clearly have a need to do this.
>>
>> Last week I would have suggested adding a "this packet is from me" tag on
>> the transmitted packets; but we discovered in separate socket exercise
>> that
>> you really need to be able to find and remove tags for multiple hop
>> scenarios.  Unless I'm mistaken you simply can't do this now.  I think you
>> could iterate through the tags and look for the last one, though (are
>> there
>> limitations on the number of tags you can have in a packet?).
>>
>> So, on one hand I think it is bad from a software engineering and
>> usability
>> perspective to add the quick filtering hack to the channel; but in the
>> presence of spoofing it seems to be the only reasonable way to get what
>> you
>> need done without either plumbing a new device parameter through the
>> channel
>> or updating the tags code to make it usable in this situation.
>>
>> So, at this point, I wouldn't object to adding the "hack" with an XXX
>> comment to CSMA and filing a bug against the tags code to enable us to get
>> rid of the "hack."  A tags fix would then address two related bugs.
>>
>
> While I agree with your points, regarding the implementation, another way
> would be to propagate carrying the NetDevice pointer explicitly through the
> send/receive calls.  That is, CsmaChannel::Send takes an additional
> "Ptr<NetDevice> from" argument, which is copied to the
> CsmaNetDevice::Receive() method.  This would seem to be easier from a code
> reading and debugging perspective.


Done: http://code.nsnam.org/gjc/ns-3-learning-bridge/rev/48f371a8ae8e

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