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

[Tom Henderson]

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.
> 
>     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?

Tom