[Ns-developers] virtual netdevice (Was: release update [feedback needed])

[Gustavo Carneiro]

OK, I think gjc/ns-3-tap-netdevice (actually VirtualNetDevice) is ready to
merge.  Any last minute objections?

2009/6/12 Gustavo Carneiro <gjcarneiro at gmail.com>

>
>
> 2009/6/11 Tom Henderson <tomh at tomh.org>
>
> Gustavo Carneiro wrote:
>>
>>>
>>>
>>> 2009/6/11 Gustavo Carneiro <gjcarneiro at gmail.com <mailto:
>>> gjcarneiro at gmail.com>>
>>>
>>>
>>>
>>>    2009/6/11 Gustavo Carneiro <gjcarneiro at gmail.com
>>>    <mailto:gjcarneiro at gmail.com>>
>>>
>>>        (changing subject or else a lot of disparate topics are mixed
>>>        into the same thread!)
>>>
>>>        2009/6/10 Tom Henderson <tomh at tomh.org <mailto:tomh at tomh.org>>
>>>
>>>        [...]
>>>
>>>
>>>
>>>
>>>                   Gustavo,
>>>                   - I thought you were going to clean up the
>>>                Receive/PromiscReceive
>>>                   separate functions?
>>>
>>>
>>>                I don't understand the concern here, or what I should
>>>                do.  If I remove one of them, which one do I keep?  How
>>>                can we be sure it's the right one?
>>>
>>>                 - Receive() is simpler to use and usually what we want,
>>>                but does not support simulating frames received by a
>>> bridge;
>>>
>>>                 - PromiscReceive takes more parameters, harder to use
>>>                if you  want to do something simpler, but needed for
>>>                certain scenarios.
>>>
>>>
>>>            My comment was that all of the other net devices call the
>>>            promisc callback out of Receive(), but here, the user has to
>>>            pick PromiscReceive or Receive() and I'm not sure how he or
>>>            she picks the right one.
>>>
>>>            Can you describe the use case for PromiscReceive?  You
>>>            implied bridging but I'm not seeing it.
>>>
>>>
>>>        I cannot possibly know all the use cases of VirtualNetDevice.
>>>    However, not supporting PromiscReceive will mean that not all
>>>        functionality of NetDevice is made available by
>>>        VirtualNetDevice.  Indeed, one use case is a "virtual bridge
>>>        port", i.e. a bridge port that is not physical but instead is,
>>>        for example, a TCP link.  Why this scenario or others matter is
>>>        not my job to point out, I just don't want to limit
>>>        functionality if the cost of supporting the funcionality is
>>>        low.  You seem to think the cost is high because having
>>>        PromisReceive will confuse users.  I think the whole
>>>        VirtualNetDevice is already for advanced users who know what
>>>        they are doing.  That's one of the reasons why VirtualNetDevice
>>>        does not have a "helper class".  The whole point is that
>>>        subclassing NetDevice is _a lot_ of work, work that is not
>>>        justified for certain kinds of scenarios, and VirtualNetDevice
>>>        avoids subclassing.
>>>
>>>
>>>    That being said, I realized later that it's impossible to align with
>>>    CsmaNetDevice's trace sources without the information provided by
>>>    PromiscReceive, so I removed Received and renamed PromiscReceive to
>>>    Receive.  Also renamed SetSendFromCallback to SetSendCallback, for
>>>    simplicity.  Pushed.
>>>
>>
>> OK, I did not intend to force you to remove it if you thought it was
>> useful; I was pointing out that you seemed to agree originally that this
>> could have been rolled together (as it is now) but then did not change it.
>>  My main point was that it seemed that users may be hard pressed to know
>> whether promiscReceiveCallback or receiveCallback is set, and therefore
>> which method to call.  I don't think there is any issue with your latest
>> code since you merged them.
>
>
> I couldn't help but merge them due to the csma trace sources that I copied
> over to VirtualNetDevice needing more parameters than the non-promisc
> Receive had to offer.
>
> Even now things are not 100% aligned because CsmaNetDevice::PromiscSniffer
> gives a packet with EthernetHeader included, while VirtualNetDevice does not
> (because it would make it less generic if it was constrained to mac48
> addresses), but it's the best that can be done.
>
>
>>
>>
>>>    Unfortunately now the example program is failing with a packet tag
>>>    error.  Any idea what could be wrong?
>>>
>>>
>>> Replying to myself.  SocketAddressTag was being added twice when the
>>> packet exists one UDP socket and is reinjected to enter another UDP socket,
>>> and NS-3 does not like it.  Calling Packet::RemoveAllPacketTags took care of
>>> it.
>>>
>>>
>>
>> this is perhaps a nit, but RemoveAllPacketTags() may have side effects for
>> some users; does RemovePacketTag (SocketAddressTag) not work here?
>
>
> Done.
>
>
> --
> Gustavo J. A. M. Carneiro
> INESC Porto, Telecommunications and Multimedia Unit
> "The universe is always one step beyond logic." -- Frank Herbert
>



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