[Ns-developers] Requesting help for csma promiscuous mode

[craigdo@ee.washington.edu]

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

That's what I meant by "... plumbing a new device parameter through the
channel ..."

I agree it would be easier.  I preferred using tags since it would not break
the channel API.  

I want to point out that we seem to be operating in a mode where API changes
are a non-issue.  That surprises me.

-- Craig