|
Bugzilla – Full Text Bug Listing |
| Summary: | NetDevice::GetChannel method needs clarification | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Mathieu Lacage <mathieu.lacage> |
| Component: | devices | Assignee: | ns-bugs <ns-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | craigdo, tomh |
| Priority: | P5 | ||
| Version: | ns-3-dev | ||
| Hardware: | All | ||
| OS: | All | ||
|
Description
Mathieu Lacage
2009-04-16 05:07:16 UTC
I do not understand this suggestion. It seems to be doing exactly what NetDevice::GetChannel says it will do. (In reply to comment #1) > I do not understand this suggestion. It seems to be doing exactly what > NetDevice::GetChannel says it will do. Are you allowed to return 0 from this method ? Yes, but only _before_ the device is connected to a channel. It could be argued that not being connected to a channel is allowed only as a transient state during topology setup which means that you should not return 0 _during_ simulation, because, honestly, an unconnected device should not exist ever once you are past Simulator::Run. Maybe what really makes sense here is to return 0 initially and a channel pointer once the device has been successfully associated to its host device. Does any of this matter ? I don't know: I merely pointed out something which looked like a good idea to me. Feel free to ignore it. 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. Virtual net devices will not have a channel either; e.g. Gustavo's tap device:
Ptr<Channel>
VirtualNetDevice::GetChannel (void) const
{
return Ptr<Channel> ();
}
Seems like either we need to create a new ABC for virtual devices or just change the doxygen to account for this possibility. I'd vote for the latter.
changeset: b322b179c5f6 |