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

[Gustavo Carneiro]

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