[Ns-developers] Requesting help for csma promiscuous mode(resend)

[Gustavo Carneiro]

2008/7/14 <craigdo at ee.washington.edu>:

> [ ... ]
>
> > The above plan sounds perfectly fine assuming you mean that
> > NetDevice::SetPromiscuousCallback means a callback that is
> > called for the
> > case of PACKET_OTHERHOST _only_, i.e. it is not called for
> > PACKET_HOST,
> > PACKET_BROADCAST, or PACKET_MULTICAST.
>
> This is just a policy choice regarding the *definition* of the promiscuous
> callback.  When I think of a promiscuous mode, I think of getting all
> packets.  The problem, of course, is that you'd have to pass addressing
> information up to the higher layers to let them decide whether or not this
> is one of the cases you mention above.
>
> I think the *really* important thing is to make it perfectly clear what
> this
> callback is providing.  If we're clear that it is an "everything else"
> callback then I'm fine with that.  This does mean that if you have a model
> of some kind that needs to receive everything from everywhere, it has to
> register itself as both a promiscuous handler and a non-promiscuous
> handler.
> I don't think this is a big deal, but is perhaps not intuitive; and
> something that should be made clear in the dox.


If you want a slightly cleaner API, albeit not preserving backward
compatibility (requires callback signature change), I would suggest the
solution I already protyped which adds a PacketType parameter like the one
Linux kernel uses: PACKET_HOST, PACKET_BROADCAST, PACKET_MULTICAST,
PACKET_OTHERHOST.  Then the promiscuous callback could receive _all_ packets
because it would be easy to filter.


> > If that is so, it
> > sounds perfectly
> > reasonable and I'll just go ahead with the implementation.
>
> Okay.  Everyone else, comment now or forever hold your peace ...
>
> > And best of all it looks like API compatibility is preserved :-)
>
> We do that every once in a while just to keep you on your toes :-)


Bah, I just realized API compat. cannot be preserved anyway because of the
protocol handler signature change (needs an extra destination address
parameter) :-(

The only solution that truly preserves API compat. is the one with two
protocol handler registration functions.  But I can understand that
increasing API size just for this may not be desired and am willing to break
API.

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