[Ns-developers] Requesting help for csma promiscuous mode

[Tom Henderson]

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.

Tom