From nfd-call-notification at mail1.yoursunny.com Thu Dec 1 07:00:04 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 1 Dec 2016 08:00:04 -0700 Subject: [Nfd-dev] NFD call 20161201 Message-ID: <201612011500.uB1F04e8023508@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From siham.khoussi at nist.gov Mon Dec 5 08:23:27 2016 From: siham.khoussi at nist.gov (Khoussi, Siham (IntlAssoc)) Date: Mon, 5 Dec 2016 16:23:27 +0000 Subject: [Nfd-dev] Choosing a layer to implement a tool Message-ID: Dear all, I would like to know what is the preferred approach to developing a tool. Is it better to do it in the application layer or in the strategy layer? What are the pros and cons to each of them? Thank you Siham -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Dec 5 17:12:09 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 5 Dec 2016 18:12:09 -0700 Subject: [Nfd-dev] Choosing a layer to implement a tool In-Reply-To: References: Message-ID: Hi Siham Since you did not describe the functionality of the tool, I'll answer in general. I'd refer to the classical paper END TO END ARGUMENT: Implement your tool in application layer. If a strategy can *enhance the performance* of your tool, you can change the strategy. Yours, Junxiao On Mon, Dec 5, 2016 at 9:23 AM, Khoussi, Siham (IntlAssoc) < siham.khoussi at nist.gov> wrote: > Dear all, > > > > I would like to know what is the preferred approach to developing a tool. > Is it better to do it in the application layer or in the strategy layer? > What are the pros and cons to each of them? > > > > Thank you > > > > Siham > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzhang at cs.arizona.edu Mon Dec 5 17:41:34 2016 From: bzhang at cs.arizona.edu (Beichuan Zhang) Date: Tue, 6 Dec 2016 09:41:34 +0800 Subject: [Nfd-dev] Choosing a layer to implement a tool In-Reply-To: References: Message-ID: <24CA074B-DA93-4237-9C5E-7A94AE84789A@cs.arizona.edu> Strategy is for changing packet forwarding behavior; applications are the source and sink of Interest/Data. Beichuan > On Dec 6, 2016, at 12:23 AM, Khoussi, Siham (IntlAssoc) wrote: > > Dear all, > > I would like to know what is the preferred approach to developing a tool. Is it better to do it in the application layer or in the strategy layer? What are the pros and cons to each of them? > > Thank you > > Siham > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Tue Dec 6 06:00:03 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 6 Dec 2016 07:00:03 -0700 Subject: [Nfd-dev] NFD call 20161206 Message-ID: <201612061400.uB6E03Zn027827@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Tue Dec 6 07:32:04 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Tue, 6 Dec 2016 15:32:04 +0000 Subject: [Nfd-dev] NFD call 20161206 In-Reply-To: <201612061400.uB6E03Zn027827@lectura.cs.arizona.edu> References: <201612061400.uB6E03Zn027827@lectura.cs.arizona.edu> Message-ID: I added an issue: Flume Application Use Case Needs: Peter Gusev, Junxiao Shi, Alex Afanasyev, Nick Gordon Lan On Dec 6, 2016, at 8:00 AM, NFD call notification > wrote: Dear folks This is a reminder of the upcoming NFD call using Bluejeans https://bluejeans.com/394441725. The current call time is every Tuesday 12:00-13:00 Pacific time and every Thursday 13:00-14:00 Pacific time. The current agenda includes the following issues: ________________________________ _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Thu Dec 8 07:00:05 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 8 Dec 2016 08:00:05 -0700 Subject: [Nfd-dev] NFD call 20161208 Message-ID: <201612081500.uB8F05sI014614@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From malhowaidi at gmail.com Thu Dec 8 09:47:00 2016 From: malhowaidi at gmail.com (Mohammad Alhowaidi) Date: Thu, 8 Dec 2016 11:47:00 -0600 Subject: [Nfd-dev] Calling consumer from NFD code Message-ID: Hello, I am trying to send an interest when a data arrive the router. I do that in the function Forwarder::onIncomingData in the NFD code,(so the consumer is called for NFD code), but it seems the interest never go and always reach timeout and doesn't reach the producer. Is there something preventing the consumer from sending the interest? Thanks, Mohammad -------------- next part -------------- An HTML attachment was scrubbed... URL: From mastorakis at CS.UCLA.EDU Thu Dec 8 09:50:13 2016 From: mastorakis at CS.UCLA.EDU (Spyridon (Spyros) Mastorakis) Date: Thu, 8 Dec 2016 09:50:13 -0800 Subject: [Nfd-dev] Calling consumer from NFD code In-Reply-To: References: Message-ID: Hi, Are you using ndnSIM? In ndnSIM, you can enable the nfd.Forwarder logging component and see what is going with your Interest in the Forwarder module. Thanks, Spyridon (Spyros) Mastorakis Personal Website: http://cs.ucla.edu/~mastorakis/ Internet Research Laboratory Computer Science Department UCLA > On Dec 8, 2016, at 9:47 AM, Mohammad Alhowaidi wrote: > > Hello, > > I am trying to send an interest when a data arrive the router. I do that in the function Forwarder::onIncomingData in the NFD code,(so the consumer is called for NFD code), but it seems the interest never go and always reach timeout and doesn't reach the producer. > > Is there something preventing the consumer from sending the interest? > > Thanks, > Mohammad -------------- next part -------------- An HTML attachment was scrubbed... URL: From malhowaidi at gmail.com Thu Dec 8 10:00:39 2016 From: malhowaidi at gmail.com (Mohammad Alhowaidi) Date: Thu, 8 Dec 2016 12:00:39 -0600 Subject: [Nfd-dev] Calling consumer from NFD code In-Reply-To: References: Message-ID: I am not using ndnSIM, I am running my experiments on VMs. Thanks, Mohammad On Thu, Dec 8, 2016 at 11:50 AM, Spyridon (Spyros) Mastorakis < mastorakis at cs.ucla.edu> wrote: > Hi, > > Are you using ndnSIM? > > In ndnSIM, you can enable the nfd.Forwarder logging component and see what > is going with your Interest in the Forwarder module. > > Thanks, > > Spyridon (Spyros) Mastorakis > Personal Website: http://cs.ucla.edu/~mastorakis/ > Internet Research Laboratory > Computer Science Department > UCLA > > On Dec 8, 2016, at 9:47 AM, Mohammad Alhowaidi > wrote: > > Hello, > > I am trying to send an interest when a data arrive the router. I do that > in the function Forwarder::onIncomingData in the NFD code,(so the consumer > is called for NFD code), but it seems the interest never go and always > reach timeout and doesn't reach the producer. > > Is there something preventing the consumer from sending the interest? > > Thanks, > Mohammad > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From malhowaidi at gmail.com Thu Dec 8 13:14:58 2016 From: malhowaidi at gmail.com (Mohammad Alhowaidi) Date: Thu, 8 Dec 2016 15:14:58 -0600 Subject: [Nfd-dev] Calling consumer from NFD code In-Reply-To: References: Message-ID: I run the NFD with TRACE option, I was mistaken, the interest will go but the data is not received, here the log , I marked by red the last three line which I think its the error (probably not). Any help? my interest name is /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.666152 TRACE: [LinkService] [id=264,local=unix:///run/nfd.sock,remote=fd://29] receiveInterest 1481230655.666194 DEBUG: [Forwarder] onIncomingInterest face=264 interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.666254 TRACE: [NameTree] lookup /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.666300 TRACE: [NameTreeHashtable] found / hash=0 bucket=0 1481230655.666356 TRACE: [NameTreeHashtable] found /ndn hash=6181921638449679482 bucket=122 1481230655.666403 TRACE: [NameTreeHashtable] found /ndn/44 hash=7352304724033790321 bucket=369 1481230655.666438 TRACE: [NameTreeHashtable] found /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34 hash=10986399680431118961 bucket=625 1481230655.666523 TRACE: [NameTreeHashtable] insert /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 hash=6488493601744978189 bucket=269 1481230655.666566 DEBUG: [ContentStore] find /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 L 1481230655.666652 DEBUG: [ContentStore] no-match 1481230655.666733 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.666799 TRACE: [Strategy] lookupFib noLinkObject found=/ndn 1481230655.666879 DEBUG: [Forwarder] onOutgoingInterest face=260 interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.666927 TRACE: [LinkService] [id=260,local=udp4:// 10.71.103.20:6363,remote=udp4://10.71.102.53:6363] sendInterest 1481230655.667007 TRACE: [UnicastUdpTransport] [id=260,local=udp4:// 10.71.103.20:6363,remote=udp4://10.71.102.53:6363] doSend 1481230655.667114 DEBUG: [BestRouteStrategy2] /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02?ndn.MaxSuffixComponents=2&ndn.Nonce=1808191983 from=264 newPitEntry-to=260 1481230655.667186 TRACE: [LinkService] [id=264,local=unix:///run/nfd.sock,remote=fd://29] receiveInterest 1481230655.667244 DEBUG: [Forwarder] onIncomingInterest face=264 interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.667291 TRACE: [NameTree] lookup /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.667349 TRACE: [NameTreeHashtable] found / hash=0 bucket=0 1481230655.667399 TRACE: [NameTreeHashtable] found /ndn hash=6181921638449679482 bucket=122 1481230655.667437 TRACE: [NameTreeHashtable] found /ndn/44 hash=7352304724033790321 bucket=369 1481230655.667489 TRACE: [NameTreeHashtable] found /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34 hash=10986399680431118961 bucket=625 1481230655.667535 TRACE: [NameTreeHashtable] found /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 hash=6488493601744978189 bucket=269 1481230655.667603 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.667661 DEBUG: [BestRouteStrategy2] /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02?ndn.MaxSuffixComponents=2&ndn.Nonce=681845873 from=264 suppressed 1481230655.667726 TRACE: [LinkService] [id=264,local=unix:///run/nfd.sock,remote=fd://29] receiveInterest 1481230655.667780 DEBUG: [Forwarder] onIncomingInterest face=264 interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.667840 TRACE: [NameTree] lookup /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.667890 TRACE: [NameTreeHashtable] found / hash=0 bucket=0 1481230655.667927 TRACE: [NameTreeHashtable] found /ndn hash=6181921638449679482 bucket=122 1481230655.667978 TRACE: [NameTreeHashtable] found /ndn/44 hash=7352304724033790321 bucket=369 1481230655.668024 TRACE: [NameTreeHashtable] found /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34 hash=10986399680431118961 bucket=625 1481230655.668095 TRACE: [NameTreeHashtable] found /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 hash=6488493601744978189 bucket=269 1481230655.668159 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.668218 DEBUG: [BestRouteStrategy2] /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02?ndn.MaxSuffixComponents=2&ndn.Nonce=3180116241 from=264 suppressed 1481230655.668281 TRACE: [LinkService] [id=264,local=unix:///run/nfd.sock,remote=fd://29] receiveInterest 1481230655.668337 DEBUG: [Forwarder] onIncomingInterest face=264 interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.668383 TRACE: [NameTree] lookup /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.668423 TRACE: [NameTreeHashtable] found / hash=0 bucket=0 1481230655.668479 TRACE: [NameTreeHashtable] found /ndn hash=6181921638449679482 bucket=122 1481230655.668530 TRACE: [NameTreeHashtable] found /ndn/44 hash=7352304724033790321 bucket=369 1481230655.668568 TRACE: [NameTreeHashtable] found /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34 hash=10986399680431118961 bucket=625 1481230655.668608 TRACE: [NameTreeHashtable] found /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 hash=6488493601744978189 bucket=269 1481230655.668662 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.668730 DEBUG: [BestRouteStrategy2] /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02?ndn.MaxSuffixComponents=2&ndn.Nonce=4013909888 from=264 suppressed 1481230655.668798 TRACE: [InternalForwarderTransport] [id=1,local=internal://,remote=internal://] receiveFromLink 1481230655.668861 TRACE: [LinkService] [id=1,local=internal://,remote=internal://] receiveData 1481230655.668911 DEBUG: [Forwarder] onIncomingData face=1 data=/localhost/nfd/faces/events/%FE%0A 1481230655.668973 TRACE: [NameTreeHashtable] not-found /localhost/nfd/faces/events/%FE%0A hash=9958661621874513940 bucket=20 1481230655.669026 TRACE: [NameTreeHashtable] found /localhost/nfd/faces/events hash=1233637898983554347 bucket=299 1481230655.669085 TRACE: [NameTreeIterator] initialized entry=/localhost/nfd/faces/events ref=/localhost/nfd/faces/events state=0 1481230655.669131 TRACE: [NameTreeIterator] advanced end 1481230655.669172 DEBUG: [ContentStore] insert /localhost/nfd/faces/events/%FE%0A 1481230655.669230 DEBUG: [Forwarder] onIncomingData matching=/localhost/nfd/faces/events 1481230655.669290 DEBUG: [Strategy] beforeSatisfyInterest pitEntry=/localhost/nfd/faces/events inFace=1 data=/localhost/nfd/faces/events/%FE%0A 1481230655.669371 DEBUG: [Forwarder] onOutgoingData face=258 data=/localhost/nfd/faces/events/%FE%0A 1481230655.669424 TRACE: [LinkService] [id=258,local=unix:///run/nfd.sock,remote=fd://25] sendData 1481230655.669493 TRACE: [UnixStreamTransport] [id=258,local=unix:///run/nfd.sock,remote=fd://25] doSend 1481230655.669631 TRACE: [RibManager] onNotification: FaceEventNotification(Kind: created, FaceID: 264, RemoteUri: fd://29, LocalUri: unix:///run/nfd.sock, FaceScope: local, FacePersistency: on-demand, LinkType: point-to-point, Flags: 0) 1481230655.669766 TRACE: [UnicastUdpTransport] [id=263,local=udp4:// 10.71.103.20:6363,remote=udp4://10.71.103.58:6363] Successfully sent: 4797 bytes 1481230655.669809 TRACE: [UnicastUdpTransport] [id=263,local=udp4:// 10.71.103.20:6363,remote=udp4://10.71.103.58:6363] Received: 67 bytes 1481230655.669884 TRACE: [LinkService] [id=263,local=udp4:// 10.71.103.20:6363,remote=udp4://10.71.103.58:6363] receiveInterest 1481230655.669934 DEBUG: [Forwarder] onIncomingInterest face=263 interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34 1481230655.669990 TRACE: [NameTree] lookup /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34 1481230655.670044 TRACE: [NameTreeHashtable] found / hash=0 bucket=0 1481230655.670106 TRACE: [NameTreeHashtable] found /ndn hash=6181921638449679482 bucket=122 1481230655.670157 TRACE: [NameTreeHashtable] found /ndn/44 hash=7352304724033790321 bucket=369 1481230655.670206 TRACE: [NameTreeHashtable] found /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34 hash=10986399680431118961 bucket=625 1481230655.670265 DEBUG: [ContentStore] find /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34 L 1481230655.670315 DEBUG: [ContentStore] matching /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%00 1481230655.670378 DEBUG: [Forwarder] onContentStoreHit interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34 1481230655.670421 DEBUG: [Forwarder] onOutgoingData face=263 data=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%00 1481230655.670472 TRACE: [LinkService] [id=263,local=udp4:// 10.71.103.20:6363,remote=udp4://10.71.103.58:6363] sendData 1481230655.670525 TRACE: [UnicastUdpTransport] [id=263,local=udp4:// 10.71.103.20:6363,remote=udp4://10.71.103.58:6363] doSend 1481230655.670613 TRACE: [DeadNonceList] adjustCapacity DOWN capacity=8 1481230655.670665 TRACE: [DeadNonceList] mark nMarks=8 1481230655.670719 TRACE: [UnicastUdpTransport] [id=260,local=udp4:// 10.71.103.20:6363,remote=udp4://10.71.102.53:6363] Successfully sent: 68 bytes 1481230655.670770 TRACE: [UnixStreamTransport] [id=264,local=unix:///run/nfd.sock,remote=fd://29] processErrorCode 1481230655.670809 INFO: [Transport] [id=264,local=unix:///run/nfd.sock,remote=fd://29] setState UP -> FAILED 1481230655.670874 TRACE: [UnixStreamTransport] [id=264,local=unix:///run/nfd.sock,remote=fd://29] doClose On Thu, Dec 8, 2016 at 12:00 PM, Mohammad Alhowaidi wrote: > I am not using ndnSIM, I am running my experiments on VMs. > > Thanks, > Mohammad > > On Thu, Dec 8, 2016 at 11:50 AM, Spyridon (Spyros) Mastorakis < > mastorakis at cs.ucla.edu> wrote: > >> Hi, >> >> Are you using ndnSIM? >> >> In ndnSIM, you can enable the nfd.Forwarder logging component and see >> what is going with your Interest in the Forwarder module. >> >> Thanks, >> >> Spyridon (Spyros) Mastorakis >> Personal Website: http://cs.ucla.edu/~mastorakis/ >> Internet Research Laboratory >> Computer Science Department >> UCLA >> >> On Dec 8, 2016, at 9:47 AM, Mohammad Alhowaidi >> wrote: >> >> Hello, >> >> I am trying to send an interest when a data arrive the router. I do that >> in the function Forwarder::onIncomingData in the NFD code,(so the consumer >> is called for NFD code), but it seems the interest never go and always >> reach timeout and doesn't reach the producer. >> >> Is there something preventing the consumer from sending the interest? >> >> Thanks, >> Mohammad >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Dec 8 13:50:13 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 8 Dec 2016 14:50:13 -0700 Subject: [Nfd-dev] Calling consumer from NFD code In-Reply-To: References: Message-ID: Hi Mohammad > my interest name is /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 From the log snippet, this Interest name appears in four Interests, all coming from face 264. The first one is forwarded. Other three are not forwarded, because they are received shortly after the initial Interest packet, so they are aggregated into the existing PIT entry. 1481230655.666194 DEBUG: [Forwarder] onIncomingInterest face=264 interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.666733 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.666799 TRACE: [Strategy] lookupFib noLinkObject found=/ndn 1481230655.666879 DEBUG: [Forwarder] onOutgoingInterest face=260 interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.667114 DEBUG: [BestRouteStrategy2] /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02?ndn.MaxSuffixComponents=2&ndn.Nonce=1808191983 from=264 newPitEntry-to=260 1481230655.667244 DEBUG: [Forwarder] onIncomingInterest face=264 interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.667603 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.667661 DEBUG: [BestRouteStrategy2] /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02?ndn.MaxSuffixComponents=2&ndn.Nonce=681845873 from=264 suppressed 1481230655.667780 DEBUG: [Forwarder] onIncomingInterest face=264 interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.668159 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.668218 DEBUG: [BestRouteStrategy2] /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02?ndn.MaxSuffixComponents=2&ndn.Nonce=3180116241 from=264 suppressed 1481230655.668337 DEBUG: [Forwarder] onIncomingInterest face=264 interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.668662 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02 1481230655.668730 DEBUG: [BestRouteStrategy2] /ndn/44/d83ef13781d9c0f6d6a825f1000ebe38752d34/%00%02?ndn.MaxSuffixComponents=2&ndn.Nonce=4013909888 from=264 suppressed The last three lines simply mean the application on face 264 is exiting. > I run the NFD with TRACE option, I was mistaken, the interest will go but the data is not received, here the log , I marked by red the last three line which I think its the error (probably not). Any help? > > 1481230655.670770 TRACE: [UnixStreamTransport] [id=264,local=unix:///run/nfd.sock,remote=fd://29] processErrorCode > 1481230655.670809 INFO: [Transport] [id=264,local=unix:///run/nfd.sock,remote=fd://29] setState UP -> FAILED > 1481230655.670874 TRACE: [UnixStreamTransport] [id=264,local=unix:///run/nfd.sock,remote=fd://29] doClose Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Tue Dec 13 06:00:05 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 13 Dec 2016 07:00:05 -0700 Subject: [Nfd-dev] NFD call 20161213 Message-ID: <201612131400.uBDE05qs024662@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From zkong at umass.edu Wed Dec 14 17:06:27 2016 From: zkong at umass.edu (Zixin Kong) Date: Wed, 14 Dec 2016 20:06:27 -0500 Subject: [Nfd-dev] Question about getting nfd connected Message-ID: <0848D0B5-8A38-4D84-8B49-E07152BB4263@umass.edu> Hello, If I want to connect to another machine not using IP address( udp4 ), is there any other way like MAC address? And what?s the format of that? Thanks so much. Best, Zixin Kong From enewberry at email.arizona.edu Wed Dec 14 17:10:55 2016 From: enewberry at email.arizona.edu (Eric Newberry) Date: Wed, 14 Dec 2016 18:10:55 -0700 Subject: [Nfd-dev] Question about getting nfd connected In-Reply-To: <0848D0B5-8A38-4D84-8B49-E07152BB4263@umass.edu> References: <0848D0B5-8A38-4D84-8B49-E07152BB4263@umass.edu> Message-ID: <0516c2e5-2d91-78c5-394a-bd72ca214956@email.arizona.edu> Zixin, You should be able to do this using an Ethernet face. -Eric On 12/14/2016 06:06 PM, Zixin Kong wrote: > Hello, > > If I want to connect to another machine not using IP address( udp4 ), is there any other way like MAC address? And what?s the format of that? > Thanks so much. > > Best, > Zixin Kong > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From enewberry at email.arizona.edu Wed Dec 14 18:20:32 2016 From: enewberry at email.arizona.edu (Eric Newberry) Date: Wed, 14 Dec 2016 19:20:32 -0700 Subject: [Nfd-dev] Question about getting nfd connected In-Reply-To: <134F4329-16F8-4238-95BA-D70BE5CE409A@umass.edu> References: <0848D0B5-8A38-4D84-8B49-E07152BB4263@umass.edu> <0516c2e5-2d91-78c5-394a-bd72ca214956@email.arizona.edu> <134F4329-16F8-4238-95BA-D70BE5CE409A@umass.edu> Message-ID: Only multicast Ethernet faces are supported by NFD. They should be created automatically on upon starting NFD for every interface that supports multicast. However, this will only happen if the "face_system.ether.mcast" NFD option is set to "yes". -Eric On 12/14/2016 06:19 PM, Zixin Kong wrote: > Hi Eric, > You mean using ?ether?? I tried using the command ? nfdc create / > ether://[02:0d:51:1e:33:dc] ?, but it didn?t work. > So I guess it might be wrong with the format. Could you clarify what > is the format of that? > > Thanks, > Zixin > > >> On Dec 14, 2016, at 8:10 PM, Eric Newberry >> > wrote: >> >> Zixin, >> >> You should be able to do this using an Ethernet face. >> >> -Eric >> >> >> On 12/14/2016 06:06 PM, Zixin Kong wrote: >>> Hello, >>> >>> If I want to connect to another machine not using IP address( udp4 >>> ), is there any other way like MAC address? And what?s the format >>> of that? >>> Thanks so much. >>> >>> Best, >>> Zixin Kong >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Thu Dec 15 07:00:03 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 15 Dec 2016 08:00:03 -0700 Subject: [Nfd-dev] NFD call 20161215 Message-ID: <201612151500.uBFF03Hi015199@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From bzhang at cs.arizona.edu Thu Dec 15 08:55:53 2016 From: bzhang at cs.arizona.edu (Beichuan Zhang) Date: Thu, 15 Dec 2016 09:55:53 -0700 Subject: [Nfd-dev] NFD call 20161215 In-Reply-To: <201612151500.uBFF03Hi015199@lectura.cs.arizona.edu> References: <201612151500.uBFF03Hi015199@lectura.cs.arizona.edu> Message-ID: Due to a schedule conflict, today's nfd call is cancelled. Beichuan On Dec 15, 2016 8:00 AM, "NFD call notification" < nfd-call-notification at mail1.yoursunny.com> wrote: Dear folks This is a reminder of the upcoming NFD call using Bluejeans https://bluejeans.com/424982807. The current call time is every Tuesday 12:00-13:00 Pacific time and every Thursday 13:00-14:00 Pacific time. The current agenda includes the following issues: ------------------------------ https://docs.google.com/document/d/1BV8GpNpRen_XCqfH8y9n357LfVL8tH3_ N60jTmRy3mA/edit Flume Application Use Case Needs: Peter Gusev, Junxiao Shi, Alex Afanasyev, Nick Gordon _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrchwdhr at memphis.edu Thu Dec 15 11:07:58 2016 From: mrchwdhr at memphis.edu (Muktadir R Chowdhury (mrchwdhr)) Date: Thu, 15 Dec 2016 19:07:58 +0000 Subject: [Nfd-dev] how does advance clock works Message-ID: Hi, Here is the definition of advanceClock in NLSR: https://github.com/named-data/NLSR/blob/master/tests/test-common.hpp#L66. We are trying to write a unit-test for Fib::scheduleEntryRefresh() (which is currently under review in gerrit) at line 449 in https://gerrit.named-data.net/#/c/2011/8/src/route/fib.cpp. The method calls Fib::refreshEntry(), which actually renews the next hops, and at the end again schedules another refresh by calling Fib::scheduleEntryRefresh(). The unit-test is at line 310 in https://gerrit.named-data.net/#/c/2011/8/tests/test-fib.cpp As I commented on gerrit, if I don't do advanceClock() the scheduled refresh does not occur. But if I advanceClock() then it gets in an infinite loop, because Fib::scheduleEntryRefresh() and Fib::refreshEntry() calls each other recursively. This is how I advance clock this->advanceClocks(ndn::time::milliseconds(1)); Am I doing anything wrong? Muktadir -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Tue Dec 20 06:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 20 Dec 2016 07:00:02 -0700 Subject: [Nfd-dev] NFD call 20161220 Message-ID: <201612201400.uBKE02xL016317@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Dec 21 09:18:54 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 21 Dec 2016 10:18:54 -0700 Subject: [Nfd-dev] PIT matching exclude question Message-ID: Hi Sonu Can you provide tcpdump (not ndndump) trace from the node in question? Capture one trace on every interface used in the experiment. If some traffic is from an application on that node, force the application to use TCP transport (set NDN_CLIENT_TRANSPORT=tcp4://127.0.0.1:6363 environ), and tcpdump at lo interface. Also, all bug reports should be sent to nfd-dev mailing list, not individual developers. Have a look at http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2016-May/ 001748.html on how to write a bug report effectively. Yours, Junxiao On Wed, Dec 21, 2016 at 9:05 AM, Lixia Zhang wrote: > > > > Suppose a node *x*, which has received data A in round 3, has a data > interest *m*: data/interest/prefix/03.exclude outstanding. It then > receives a new data interest *n:* data/interest/prefix/03.exclude > from another node *y*. The RoundSync at node *x* sends data A with name > data/interest/prefix/03 to satisfy the interest *n.* However the NFD also > marks the outstanding interest *m* as satisfied because it has the same > name. Now if a legitimate data B arrives at node *x*, which could satisfy > interest *m*, the NFD discards the data. > > > I copied Junxiao and Beichuan on this reply: the above seems an > implementation bug: the PIT entry management considered the name matching > only, but in this case one must consider the exclude filter, otherwise it > does the wrong thing (e.g.your question-1) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tteixeira at engin.umass.edu Wed Dec 21 14:14:01 2016 From: tteixeira at engin.umass.edu (Thiago Teixeira) Date: Wed, 21 Dec 2016 22:14:01 +0000 Subject: [Nfd-dev] Ethernet multicast over multiple wireless hops Message-ID: <5a80a39b92174530b3c95b20525ee710@engin.umass.edu> Hi, I have a topology of five wireless nodes all running NFD v.0.5. on Ubuntu 16.04. I am using Ethernet as the transport method with one multicast group, as follows face_system.ether. mcast_group 01:00:5E:00:17:AA. I am using "nfdc register /ndn/broadcast ether://[01:00:5E:00:17:AA]" to register nodes to the multicast group, which creates the following faces: Faces: faceid=1 remote=internal:// local=internal:// counters={in={0i 19d 0n 10752B} out={29i 0d 0n 2940B}} local permanent point-to-point flags={local-fields} faceid=254 remote=contentstore:// local=contentstore:// counters={in={0i 0d 0n 0B} out={0i 0d 0n 0B}} local permanent point-to-point flags={} faceid=255 remote=null:// local=null:// counters={in={0i 0d 0n 0B} out={0i 0d 0n 0B}} local permanent point-to-point flags={} faceid=256 remote=udp4://224.0.23.170:56363 local=udp4://10.0.0.9:56363 counters={in={0i 0d 0n 0B} out={0i 0d 0n 0B}} non-local permanent multi-access flags={} faceid=257 remote=ether://[01:00:5e:00:17:aa] local=dev://eth0 counters={in={0i 0d 0n 0B} out={0i 0d 0n 0B}} non-local permanent multi-access flags={} faceid=258 remote=fd://25 local=unix:///run/nfd.sock counters={in={18i 2d 0n 3297B} out={3i 10d 0n 6406B}} local on-demand point-to-point flags={local-fields} faceid=261 remote=fd://26 local=unix:///run/nfd.sock counters={in={6i 0d 0n 314B} out={0i 0d 0n 0B}} local on-demand point-to-point flags={} FIB: /localhost/nfd/rib nexthops={faceid=258 (cost=0)} /ndn/broadcast nexthops={faceid=257 (cost=0)} /localhost/nfd nexthops={faceid=1 (cost=0)} RIB: /ndn/broadcast route={faceid=257 (origin=255 cost=0 ChildInherit)} /localhost/nfd route={faceid=258 (origin=0 cost=0 ChildInherit)} When I test connectivity using NDN-Ping it works between one hop neighbors, but not over multiple hops. I assume that is because the architecture prevents it from sending Int/Data packets over the same face it received, in order to prevent loops. Am I right? If so, what is the best way to address this issue? Thanks, Thiago PS: my issue is a bit different from this (http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2015-April/001018.html) because I have only one Ethernet interface. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Dec 21 17:46:06 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 21 Dec 2016 18:46:06 -0700 Subject: [Nfd-dev] Ethernet multicast over multiple wireless hops In-Reply-To: <5a80a39b92174530b3c95b20525ee710@engin.umass.edu> References: <5a80a39b92174530b3c95b20525ee710@engin.umass.edu> Message-ID: Hi Thiago NFD forwarding as of v0.5.0 is not designed for wireless networks. Whether an Interest will be forwarded out of the same face as it came in is up to the strategy, as nothing in forwarding pipelines prevents such forwarding. For BestRouteStrategy2, delete these lines https://github.com/named-data/NFD/blob/037f4ab4b62f42447c78d25ede0755f98409c9cb/daemon/fw/best-route-strategy2.cpp#L71-L73 enables such forwarding. Incoming Data pipeline will not forward a Data out of the same face as it came in. This can be changed by deleting these lines https://github.com/named-data/NFD/blob/037f4ab4b62f42447c78d25ede0755f98409c9cb/daemon/fw/forwarder.cpp#L365-L367 I do not know the implication on loop detection and PIT aggregation after those changes are made. I'm CCing Teng Liang who recently implemented a broadcast-based forwarding strategy for sensor networks where each node has only one wireless NIC, as he may have a better idea on the implication. Yours, Junxiao On Wed, Dec 21, 2016 at 3:14 PM, Thiago Teixeira wrote: > I have a topology of five wireless nodes all running NFD v.0.5. on Ubuntu > 16.04. I am using Ethernet as the transport method with one multicast > group, as follows *face_system.ether. **mcast_group 01:00:5E:00:17:AA*. > > > When I test connectivity using NDN-Ping it works between one hop > neighbors, but not over multiple hops. I assume that is because the > architecture prevents it from sending Int/Data packets over the same face > it received, in order to prevent loops. Am I right? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Thu Dec 22 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 22 Dec 2016 08:00:02 -0700 Subject: [Nfd-dev] NFD call 20161222 Message-ID: <201612221500.uBMF02UI000532@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From invite at bluejeans.com Fri Dec 23 03:51:36 2016 From: invite at bluejeans.com (Lan Wang via Blue Jeans Network) Date: Fri, 23 Dec 2016 11:51:36 +0000 (UTC) Subject: [Nfd-dev] Updated: NDN Platform Development Call Tuesday Message-ID: <489779648.37491482493896104.JavaMail.denimuser@sj1-app-26-67> To join the meeting on a computer or mobile phone: https://bluejeans.com/394441725?src=textEmail Lan Wang has updated the information for your video meeting. Meeting Title: NDN Platform Development Call Tuesday Meeting Time (Updated): Every Tuesday from November 8, 2016 through January 3, 2017 2 p.m. CST / 1 hr ------------------------------------------------ Connecting directly from a room system? 1) Dial: 199.48.152.152 or bjn.vc 2) Enter Meeting ID: 394441725 Just want to dial in on your phone? 1) +1.408.740.7256 (US) +1.888.240.2560 (US Toll Free) +1.408.317.9253 (Alternate number) (http://bluejeans.com/numbers) 2) Enter Meeting ID: 394441725 3) Press # ------------------------------------------------ Want to test your video connection? http://bluejeans.com/111 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1722 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1722 bytes Desc: not available URL: From invite at bluejeans.com Fri Dec 23 03:52:22 2016 From: invite at bluejeans.com (Blue Jeans Network) Date: Fri, 23 Dec 2016 11:52:22 +0000 (UTC) Subject: [Nfd-dev] CANCELED: NDN Platform Development Call Tuesday Message-ID: <2023252412.37511482493942676.JavaMail.denimuser@sj1-app-26-67> Lan Wang (lanwang at memphis.edu) has cancelled the following meeting: Meeting Title: NDN Platform Development Call Tuesday Meeting Time: Tuesday December 27, 2016 2 p.m. CST / 1 hr ************************************************ ? Blue Jeans Network 2016 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1195 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1195 bytes Desc: not available URL: From invite at bluejeans.com Fri Dec 23 03:53:01 2016 From: invite at bluejeans.com (Lan Wang via Blue Jeans Network) Date: Fri, 23 Dec 2016 11:53:01 +0000 (UTC) Subject: [Nfd-dev] Updated: NDN Platform Development Call Thursday Message-ID: <342274520.37661482493981702.JavaMail.denimuser@sj1-app-26-60> To join the meeting on a computer or mobile phone: https://bluejeans.com/424982807?src=textEmail Lan Wang has updated the information for your video meeting. Meeting Title: NDN Platform Development Call Thursday Meeting Time (Updated): Every Thursday from November 10, 2016 through January 5, 2017 3 p.m. CST / 1 hr ------------------------------------------------ Connecting directly from a room system? 1) Dial: 199.48.152.152 or bjn.vc 2) Enter Meeting ID: 424982807 Just want to dial in on your phone? 1) +1.408.740.7256 (US) +1.888.240.2560 (US Toll Free) +1.408.317.9253 (Alternate number) (http://bluejeans.com/numbers) 2) Enter Meeting ID: 424982807 3) Press # ------------------------------------------------ Want to test your video connection? http://bluejeans.com/111 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1724 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1724 bytes Desc: not available URL: From invite at bluejeans.com Fri Dec 23 03:53:24 2016 From: invite at bluejeans.com (Blue Jeans Network) Date: Fri, 23 Dec 2016 11:53:24 +0000 (UTC) Subject: [Nfd-dev] CANCELED: NDN Platform Development Call Thursday Message-ID: <1261290485.37611482494004435.JavaMail.denimuser@sj1-app-26-72> Lan Wang (lanwang at memphis.edu) has cancelled the following meeting: Meeting Title: NDN Platform Development Call Thursday Meeting Time: Thursday December 29, 2016 3 p.m. CST / 1 hr ************************************************ ? Blue Jeans Network 2016 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1197 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1197 bytes Desc: not available URL: From lanwang at memphis.edu Fri Dec 23 04:00:25 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Fri, 23 Dec 2016 12:00:25 +0000 Subject: [Nfd-dev] new NDN platform call time and information Message-ID: <87423700-E7A6-49BD-8EB4-C15DBAC2E33B@memphis.edu> Monday and Wednesday 2-3pm pacific time, starting on Jan 9. Meeting URL https://bluejeans.com/505221277 Meeting ID 505221277 Moderator Passcode 6425 Want to dial in from a phone? Dial one of the following numbers: ? +1.408.740.7256 ? +1.888.240.2560 ? +1.408.317.9253 SEE ALL NUMBERS Enter the meeting ID and passcode followed by # Connecting from a room system? Dial: 199.48.152.152 or bjn.vc and enter your meeting ID & passcode Lan From nfd-call-notification at mail1.yoursunny.com Tue Dec 27 06:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 27 Dec 2016 07:00:02 -0700 Subject: [Nfd-dev] NFD call 20161227 Message-ID: <201612271400.uBRE02Yi019798@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Thu Dec 29 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 29 Dec 2016 08:00:02 -0700 Subject: [Nfd-dev] NFD call 20161229 Message-ID: <201612291500.uBTF02xO025708@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: