[Ns-bugs] [Bug 550] TapBridge::GetChannel is not implemented

code@nsnam.ece.gatech.edu code at nsnam.ece.gatech.edu
Thu Apr 16 11:37:53 PDT 2009


http://www.nsnam.org/bugzilla/show_bug.cgi?id=550


Craig Dowell <craigdo at ee.washington.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |craigdo at ee.washington.edu




--- Comment #3 from Craig Dowell <craigdo at ee.washington.edu>  2009-04-16 14:37:53 EDT ---
I think that the real issue is that there is no way to know what is "on the
other side" of a channel connected to an emulation-type device.  It seems that
there is a special case there that may or may not need addressing depending on
the context.  Then the question is how to you decide when you have run across
the special case of possibly many reachable devices on a channel/network with
only one net device on it, and that you need to deal with it?

It seemed to me that returning zero had exactly the right implications and was
the easiest way to check for a network "leaving" ns-3.  If we create a fake
channel, we could give it a property that it was a fake channel; but this
involved some kind of test for "fakeness" to discern the special case.  If you
default to returning a "fake" channel, it allows higher level code to assume
that the channel is "real" and make possibly very wrong assumptions about
topology that could lead to hard-to-find problems much later on.

The simplest and most fail-safe thing seemed to me to be to return a zero
pointer saying, "the concept of ns-3 channel doesn't mean anything here."  If
you are using the channel, chances are you are looking for something on the
other side.  It seems good to flag this case in an obvious way.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the Ns-bugs mailing list