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

[Gustavo Carneiro]

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

>
>
> 2009/6/11 Gustavo Carneiro <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>
>> [...]
>>
>>>
>>>>
>>>>
>>>>    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.
>
> 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.


>
>
>
> 0x00007fb8a8d7709e in ns3::PacketTagList::Add (this=0xdb48a0,
> tag=@0x7fffb16f0530) at ../src/common/packet-tag-list.cc:139
> 139          NS_ASSERT (cur->tid != tag.GetInstanceTypeId ());
> (gdb) bt
> #0  0x00007fb8a8d7709e in ns3::PacketTagList::Add (this=0xdb48a0,
> tag=@0x7fffb16f0530) at ../src/common/packet-tag-list.cc:139
> #1  0x00007fb8a8d5a244 in ns3::Packet::AddPacketTag (this=0xdb4870,
> tag=@0x7fffb16f0530) at ../src/common/packet.cc:629
> #2  0x00007fb8a8e5547c in ns3::UdpSocketImpl::ForwardUp (this=0xdb4260,
> packet={m_ptr = 0x7fffb16f05f0}, ipv4=
>
>
> --
> 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