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

[Gustavo Carneiro]

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?


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