[ndnSIM] behavior of consumer and provider

Alex Afanasyev alexander.afanasyev at ucla.edu
Wed Apr 24 19:53:52 PDT 2013


Hi huyao,

What do you mean by "AppFace and NetDeviceFace share FaceId"?  Each face on the node has its own unique id, doesn't matter, NetDeviceFace of AppFace...

Your observation about the current situation with face IDs is exactly right: application faces have IDs that are numerically larger than any other NetDevice face id.  However, this happened completely by "accident" and you should not really rely on it in the forwarding strategy.  If you want to determine if a specific Ptr<Face> is actually an application face, a much safer way is to do a DynamicCast or (better, but I'm not sure yet how it can be implemented) mark application faces somehow in FIB entries:

Ptr<Face> someFace = ...;

if (DynamicCast<AppFace> (someFace))
{
   // someFace is application face
}
else
{
   // someFace is some other type of face
}

---
Alex

On Apr 24, 2013, at 5:24 PM, yao hu <huyao0107 at gmail.com> wrote:

> Hi Alex,
> 
> Thanks very much for your explicit explanation. 
> Then, for my understanding, it depends on me to decide whether the satisfied interest will be forwarded again towards other nodes (someOtherNode in your example) or not. If I send it to both AppFace and NetDeviceFace which share FaceId, it will do this. And also, from my simple observance from L3RateTracer, if one node connects to two other nodes, face 0 and face 1 is the NetDeviceFace, while face 2 will be the AppFace. Is my understanding right?
> 
> Regards,
> huyao
> 
> 
> 
> 2013/4/25 Alex Afanasyev <alexander.afanasyev at ucla.edu>
> Hi!
> 
> 1) Yes. There is something like PIT in consumer, but in much more simplistic format.  In consumer it is just a container, containing outstanding sequence number and last retransmission time (m_seqTimeouts variable in apps/ndn-consumer.h).  The code uses boost::multi_index container to have separate indices by sequence number (to efficiently remove) and retransmission time (for retransmission detection).
> 
> 2) Let me show you my understanding of your question with slightly different topology
> 
>    (NetDeviceFace)                (NetDeviceFace)
>  +--------+ /x         +--------------+ /x              +---------------+
>  | client | ---------- | producerNode | --------------- | someOtherNode |
>  +--------+            +--------------+                 +---------------+
>                               | /x (AppFace)
>                               |
>                               |
>                        +-------------+
>                        | producerApp |
>                        +-------------+
> 
> Let's say we have three nodes, one is client, one producer, and one is producerNode.  Prefix /x (under which client will be sending interests) is routed:
> - on client:  the only NetDeviceFace (towards producerNode)
> - on producerNode:  to AppFace (to producer app), to NetDeviceFace (towards someOtherNode)
> 
> When producerNode receives an interests from the client, the strategy may send interest towards application (and this interest will be satisfied) and towards some other node.
> 
> Among the existing strategies, only ns3::ndn::fw::Flooding is doing this, since it is very simple and dumb strategy.  BestRoute and SmartFlooding forward interest only to a "green" face (if available), which implies that they will forward only to the application (ndn::Producer marks the application face "green").
> 
> ---
> Alex
> 
> On Apr 24, 2013, at 8:17 AM, yao hu <huyao0107 at gmail.com> wrote:
> 
> > Hi Alex,
> >
> > I have two uncertain issues about the behavior of consumer and provider for confirmation.
> >
> > (1) Is there any record like PIT for consumer or requester to memorize past Interest transmission? Possibly for its future retransmission.
> >
> > (2) Say in a tree topology. If the root as the provider has satisfied the incoming Interest to send back its according Data. Is it possible to again forward the Interest to other branches (except the branch for the incoming Interest)? I am asking this because in my forwarding strategy, I saw some traffic in other branches, however I just modified DoPropagateInterest, no other basic ndn functions.
> >
> > Your reply will be really appreciated.
> >
> > Regards,
> > huyao
> >
> > _______________________________________________
> > ndnSIM mailing list
> > ndnSIM at lists.cs.ucla.edu
> > http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
> 
> 
> _______________________________________________
> ndnSIM mailing list
> ndnSIM at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20130424/740dc79d/attachment.html>


More information about the ndnSIM mailing list