From jefft0 at remap.ucla.edu  Mon May  5 14:30:45 2014
From: jefft0 at remap.ucla.edu (Thompson, Jeff)
Date: Mon, 5 May 2014 21:30:45 +0000
Subject: [Nfd-dev] Register prefix with remove NFD?
Message-ID: <CF8D5183.E26D%jefft0@remap.ucla.edu>

Hello,

Is it possible register a prefix by sending a command to a remote NFD?  With the current NFD, command validation is disabled.  I tried sending a register prefix command to a remote NFD but it timed out.  Should this work?  (I know eventually it would be necessary to set up the trust root on the remove NFD.)

Thanks,
- Jeff T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140505/44eb5f1a/attachment.html>

From jefft0 at remap.ucla.edu  Mon May  5 14:31:36 2014
From: jefft0 at remap.ucla.edu (Thompson, Jeff)
Date: Mon, 5 May 2014 21:31:36 +0000
Subject: [Nfd-dev] Register prefix with remote NFD?
Message-ID: <CF8D51A1.E270%jefft0@remap.ucla.edu>

[Fixing subject line]

Hello,

Is it possible register a prefix by sending a command to a remote NFD?  With the current NFD, command validation is disabled.  I tried sending a register prefix command to a remote NFD but it timed out.  Should this work?  (I know eventually it would be necessary to set up the trust root on the remove NFD.)

Thanks,
- Jeff T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140505/952b7cd4/attachment.html>

From alexander.afanasyev at ucla.edu  Mon May  5 14:34:36 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Mon, 5 May 2014 14:34:36 -0700
Subject: [Nfd-dev] Register prefix with remote NFD?
In-Reply-To: <CF8D51A1.E270%jefft0@remap.ucla.edu>
References: <CF8D51A1.E270%jefft0@remap.ucla.edu>
Message-ID: <609AAC96-947F-43D9-8873-6F58B65C75C7@ucla.edu>

It is not enabled.  If you really want it, you can uncomment the default section in config file for remote registration (localhop_security in rib section), but the default setting do enable security.  You can enable security-less registration for localhop as well, but it is dangerous, so it should not be used really.

---
Alex

On May 5, 2014, at 2:31 PM, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:

> [Fixing subject line]
> 
> Hello,
> 
> Is it possible register a prefix by sending a command to a remote NFD?  With the current NFD, command validation is disabled.  I tried sending a register prefix command to a remote NFD but it timed out.  Should this work?  (I know eventually it would be necessary to set up the trust root on the remove NFD.)
> 
> Thanks,
> - Jeff T
> _______________________________________________
> 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140505/7faeb44c/attachment.html>

From lanwang at memphis.edu  Wed May  7 11:01:01 2014
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Wed, 7 May 2014 18:01:01 +0000
Subject: [Nfd-dev] Fwd: ndn-cxx error on CentOs
References: <1399481397257.97009@memphis.edu>
Message-ID: <D3DD5865-D8C4-4856-A247-724BA8DE5CE9@memphis.edu>

One of my students is trying to install nfd and ndn-cxx on CentOS (we have several Ubuntu nodes installed already).  Below are some errors he ran into.  I know CentOS is not supported yet.  If this problem is something fixable, then we'd like to know how.

Begin forwarded message:

From: "Ashlesh Gawande (agawande)" <agawande at memphis.edu<mailto:agawande at memphis.edu>>
Subject: ndn-cxx error on CentOs
Date: May 7, 2014 11:49:52 AM CDT
To: "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>

I installed boost successfully on centOS (it was missing bzip2 devel)

This is the error I get while installing :

[37/72] cxxprogram: build/tools/ndncatchunks3.cpp.1.o -> build/tools/ndncatchunks3
./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `exists':
/usr/local/include/boost/filesystem/operations.hpp:289: undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)'
/usr/local/include/boost/filesystem/operations.hpp:289: undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)'
/usr/local/include/boost/filesystem/operations.hpp:289: undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)'
/usr/local/include/boost/filesystem/operations.hpp:289: undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)'
./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `remove':
/usr/local/include/boost/filesystem/operations.hpp:496: undefined reference to `boost::filesystem::detail::remove(boost::filesystem::path const&, boost::system::error_code*)'
./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `exists':
/usr/local/include/boost/filesystem/operations.hpp:289: undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)'
./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `remove':
/usr/local/include/boost/filesystem/operations.hpp:496: undefined reference to `boost::filesystem::detail::remove(boost::filesystem::path const&, boost::system::error_code*)'
./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `operator/':
/usr/local/include/boost/filesystem/path.hpp:648: undefined reference to `boost::filesystem::path::operator/=(boost::filesystem::path const&)'
/usr/local/include/boost/filesystem/path.hpp:648: undefined reference to `boost::filesystem::path::operator/=(boost::filesystem::path const&)'
./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `path<char*>':
/usr/local/include/boost/filesystem/path.hpp:139: undefined reference to `boost::filesystem::path::codecvt()'
./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `operator/':
/usr/local/include/boost/filesystem/path.hpp:648: undefined reference to `boost::filesystem::path::operator/=(boost::filesystem::path const&)'
/usr/local/include/boost/filesystem/path.hpp:648: undefined reference to `boost::filesystem::path::operator/=(boost::filesystem::path const&)'
./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `create_directories':
/usr/local/include/boost/filesystem/operations.hpp:399: undefined reference to `boost::filesystem::detail::create_directories(boost::filesystem::path const&, boost::system::error_code*)'
./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `operator=<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >':
/usr/local/include/boost/filesystem/path.hpp:202: undefined reference to `boost::filesystem::path::codecvt()'
./libndn-cxx.a(config-file.cpp.1.o): In function `path<char*>':
/usr/local/include/boost/filesystem/path.hpp:139: undefined reference to `boost::filesystem::path::codecvt()'
./libndn-cxx.a(config-file.cpp.1.o): In function `ndn::ConfigFile::findConfigFile()':
/home/ndnuser/ndn-cxx/build/../src/util/config-file.cpp:58: undefined reference to `boost::filesystem::path::operator/=(char const*)'
./libndn-cxx.a(config-file.cpp.1.o): In function `exists':
/usr/local/include/boost/filesystem/operations.hpp:289: undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)'
./libndn-cxx.a(config-file.cpp.1.o): In function `current_path':
/usr/local/include/boost/filesystem/operations.hpp:429: undefined reference to `boost::filesystem::detail::current_path(boost::system::error_code*)'
./libndn-cxx.a(config-file.cpp.1.o): In function `ndn::ConfigFile::findConfigFile()':
/home/ndnuser/ndn-cxx/build/../src/util/config-file.cpp:61: undefined reference to `boost::filesystem::absolute(boost::filesystem::path const&, boost::filesystem::path const&)'
/home/ndnuser/ndn-cxx/build/../src/util/config-file.cpp:67: undefined reference to `boost::filesystem::path::operator/=(char const*)'
./libndn-cxx.a(config-file.cpp.1.o): In function `exists':
/usr/local/include/boost/filesystem/operations.hpp:289: undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)'
./libndn-cxx.a(config-file.cpp.1.o): In function `current_path':
/usr/local/include/boost/filesystem/operations.hpp:429: undefined reference to `boost::filesystem::detail::current_path(boost::system::error_code*)'
./libndn-cxx.a(config-file.cpp.1.o): In function `ndn::ConfigFile::findConfigFile()':
/home/ndnuser/ndn-cxx/build/../src/util/config-file.cpp:71: undefined reference to `boost::filesystem::absolute(boost::filesystem::path const&, boost::filesystem::path const&)'
./libndn-cxx.a(config-file.cpp.1.o): In function `exists':
/usr/local/include/boost/filesystem/operations.hpp:289: undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)'
./libndn-cxx.a(config-file.cpp.1.o): In function `current_path':
/usr/local/include/boost/filesystem/operations.hpp:429: undefined reference to `boost::filesystem::detail::current_path(boost::system::error_code*)'
./libndn-cxx.a(config-file.cpp.1.o): In function `ndn::ConfigFile::findConfigFile()':
/home/ndnuser/ndn-cxx/build/../src/util/config-file.cpp:78: undefined reference to `boost::filesystem::absolute(boost::filesystem::path const&, boost::filesystem::path const&)'
./libndn-cxx.a(sec-public-info-sqlite3.cpp.1.o): In function `path<char*>':
/usr/local/include/boost/filesystem/path.hpp:139: undefined reference to `boost::filesystem::path::codecvt()'
./libndn-cxx.a(sec-public-info-sqlite3.cpp.1.o): In function `operator/':
/usr/local/include/boost/filesystem/path.hpp:648: undefined reference to `boost::filesystem::path::operator/=(boost::filesystem::path const&)'
./libndn-cxx.a(sec-public-info-sqlite3.cpp.1.o): In function `create_directories':
/usr/local/include/boost/filesystem/operations.hpp:399: undefined reference to `boost::filesystem::detail::create_directories(boost::filesystem::path const&, boost::system::error_code*)'
./libndn-cxx.a(sec-public-info-sqlite3.cpp.1.o): In function `operator/':
/usr/local/include/boost/filesystem/path.hpp:648: undefined reference to `boost::filesystem::path::operator/=(boost::filesystem::path const&)'
collect2: ld returned 1 exit status

Ashlesh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140507/024e969c/attachment.html>

From shijunxiao at email.arizona.edu  Wed May  7 11:05:30 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 7 May 2014 11:05:30 -0700
Subject: [Nfd-dev] Fwd: ndn-cxx error on CentOs
In-Reply-To: <D3DD5865-D8C4-4856-A247-724BA8DE5CE9@memphis.edu>
References: <1399481397257.97009@memphis.edu>
	<D3DD5865-D8C4-4856-A247-724BA8DE5CE9@memphis.edu>
Message-ID: <CAOFH+ObQGaA2ksg9B1DguQB8D3gtL+YH17spmwa7ZhQuC8wJYA@mail.gmail.com>

Hi Ashlesh

What version of Boost libraries do you have?
Find out with: grep 'BOOST_LIB_VERSION' /usr/local/include/boost/version.hpp

You need to have Boost 1.48 or above in order to build ndn-cxx.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140507/76c06f6e/attachment.html>

From alexander.afanasyev at ucla.edu  Wed May  7 11:20:15 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Wed, 7 May 2014 11:20:15 -0700
Subject: [Nfd-dev] Fwd: ndn-cxx error on CentOs
In-Reply-To: <D3DD5865-D8C4-4856-A247-724BA8DE5CE9@memphis.edu>
References: <1399481397257.97009@memphis.edu>
	<D3DD5865-D8C4-4856-A247-724BA8DE5CE9@memphis.edu>
Message-ID: <FF14B35C-6B91-4B94-81F1-F3FF6AC7FDFE@ucla.edu>

I saw similar errors before and it was caused by multiple versions of boost installed.

Did you specify correct --boost-libs and --boost-includes configure flags?

---
Alex

> On May 7, 2014, at 11:01 AM, "Lan Wang (lanwang)" <lanwang at memphis.edu> wrote:
> 
> One of my students is trying to install nfd and ndn-cxx on CentOS (we have several Ubuntu nodes installed already).  Below are some errors he ran into.  I know CentOS is not supported yet.  If this problem is something fixable, then we'd like to know how.  
> 
> Begin forwarded message:
> 
>> From: "Ashlesh Gawande (agawande)" <agawande at memphis.edu>
>> Subject: ndn-cxx error on CentOs
>> Date: May 7, 2014 11:49:52 AM CDT
>> To: "Lan Wang (lanwang)" <lanwang at memphis.edu>
>> 
>> I installed boost successfully on centOS (it was missing bzip2 devel)
> 
>> This is the error I get while installing :
>> 
>> [37/72] cxxprogram: build/tools/ndncatchunks3.cpp.1.o -> build/tools/ndncatchunks3
>> ./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `exists':
>> /usr/local/include/boost/filesystem/operations.hpp:289: undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)'
>> /usr/local/include/boost/filesystem/operations.hpp:289: undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)'
>> /usr/local/include/boost/filesystem/operations.hpp:289: undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)'
>> /usr/local/include/boost/filesystem/operations.hpp:289: undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)'
>> ./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `remove':
>> /usr/local/include/boost/filesystem/operations.hpp:496: undefined reference to `boost::filesystem::detail::remove(boost::filesystem::path const&, boost::system::error_code*)'
>> ./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `exists':
>> /usr/local/include/boost/filesystem/operations.hpp:289: undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)'
>> ./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `remove':
>> /usr/local/include/boost/filesystem/operations.hpp:496: undefined reference to `boost::filesystem::detail::remove(boost::filesystem::path const&, boost::system::error_code*)'
>> ./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `operator/':
>> /usr/local/include/boost/filesystem/path.hpp:648: undefined reference to `boost::filesystem::path::operator/=(boost::filesystem::path const&)'
>> /usr/local/include/boost/filesystem/path.hpp:648: undefined reference to `boost::filesystem::path::operator/=(boost::filesystem::path const&)'
>> ./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `path<char*>':
>> /usr/local/include/boost/filesystem/path.hpp:139: undefined reference to `boost::filesystem::path::codecvt()'
>> ./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `operator/':
>> /usr/local/include/boost/filesystem/path.hpp:648: undefined reference to `boost::filesystem::path::operator/=(boost::filesystem::path const&)'
>> /usr/local/include/boost/filesystem/path.hpp:648: undefined reference to `boost::filesystem::path::operator/=(boost::filesystem::path const&)'
>> ./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `create_directories':
>> /usr/local/include/boost/filesystem/operations.hpp:399: undefined reference to `boost::filesystem::detail::create_directories(boost::filesystem::path const&, boost::system::error_code*)'
>> ./libndn-cxx.a(sec-tpm-file.cpp.1.o): In function `operator=<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >':
>> /usr/local/include/boost/filesystem/path.hpp:202: undefined reference to `boost::filesystem::path::codecvt()'
>> ./libndn-cxx.a(config-file.cpp.1.o): In function `path<char*>':
>> /usr/local/include/boost/filesystem/path.hpp:139: undefined reference to `boost::filesystem::path::codecvt()'
>> ./libndn-cxx.a(config-file.cpp.1.o): In function `ndn::ConfigFile::findConfigFile()':
>> /home/ndnuser/ndn-cxx/build/../src/util/config-file.cpp:58: undefined reference to `boost::filesystem::path::operator/=(char const*)'
>> ./libndn-cxx.a(config-file.cpp.1.o): In function `exists':
>> /usr/local/include/boost/filesystem/operations.hpp:289: undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)'
>> ./libndn-cxx.a(config-file.cpp.1.o): In function `current_path':
>> /usr/local/include/boost/filesystem/operations.hpp:429: undefined reference to `boost::filesystem::detail::current_path(boost::system::error_code*)'
>> ./libndn-cxx.a(config-file.cpp.1.o): In function `ndn::ConfigFile::findConfigFile()':
>> /home/ndnuser/ndn-cxx/build/../src/util/config-file.cpp:61: undefined reference to `boost::filesystem::absolute(boost::filesystem::path const&, boost::filesystem::path const&)'
>> /home/ndnuser/ndn-cxx/build/../src/util/config-file.cpp:67: undefined reference to `boost::filesystem::path::operator/=(char const*)'
>> ./libndn-cxx.a(config-file.cpp.1.o): In function `exists':
>> /usr/local/include/boost/filesystem/operations.hpp:289: undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)'
>> ./libndn-cxx.a(config-file.cpp.1.o): In function `current_path':
>> /usr/local/include/boost/filesystem/operations.hpp:429: undefined reference to `boost::filesystem::detail::current_path(boost::system::error_code*)'
>> ./libndn-cxx.a(config-file.cpp.1.o): In function `ndn::ConfigFile::findConfigFile()':
>> /home/ndnuser/ndn-cxx/build/../src/util/config-file.cpp:71: undefined reference to `boost::filesystem::absolute(boost::filesystem::path const&, boost::filesystem::path const&)'
>> ./libndn-cxx.a(config-file.cpp.1.o): In function `exists':
>> /usr/local/include/boost/filesystem/operations.hpp:289: undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)'
>> ./libndn-cxx.a(config-file.cpp.1.o): In function `current_path':
>> /usr/local/include/boost/filesystem/operations.hpp:429: undefined reference to `boost::filesystem::detail::current_path(boost::system::error_code*)'
>> ./libndn-cxx.a(config-file.cpp.1.o): In function `ndn::ConfigFile::findConfigFile()':
>> /home/ndnuser/ndn-cxx/build/../src/util/config-file.cpp:78: undefined reference to `boost::filesystem::absolute(boost::filesystem::path const&, boost::filesystem::path const&)'
>> ./libndn-cxx.a(sec-public-info-sqlite3.cpp.1.o): In function `path<char*>':
>> /usr/local/include/boost/filesystem/path.hpp:139: undefined reference to `boost::filesystem::path::codecvt()'
>> ./libndn-cxx.a(sec-public-info-sqlite3.cpp.1.o): In function `operator/':
>> /usr/local/include/boost/filesystem/path.hpp:648: undefined reference to `boost::filesystem::path::operator/=(boost::filesystem::path const&)'
>> ./libndn-cxx.a(sec-public-info-sqlite3.cpp.1.o): In function `create_directories':
>> /usr/local/include/boost/filesystem/operations.hpp:399: undefined reference to `boost::filesystem::detail::create_directories(boost::filesystem::path const&, boost::system::error_code*)'
>> ./libndn-cxx.a(sec-public-info-sqlite3.cpp.1.o): In function `operator/':
>> /usr/local/include/boost/filesystem/path.hpp:648: undefined reference to `boost::filesystem::path::operator/=(boost::filesystem::path const&)'
>> collect2: ld returned 1 exit status
>> 
>> Ashlesh
> 
> _______________________________________________
> 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140507/6d9e8f29/attachment.html>

From shijunxiao at email.arizona.edu  Wed May  7 11:47:37 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 7 May 2014 11:47:37 -0700
Subject: [Nfd-dev] Fwd: ndn-cxx error on CentOs
Message-ID: <CAOFH+OZag7C9sYXNQ3XfGT4KWwOUBca3DSFq0jWF7C54+Hg8JA@mail.gmail.com>

Hi Ashlesh

Please attach build/config.log in NFD repository.
Please paste the lines after "collect2: ld returned 1 exit status" (it
shall contains the complete command line of g++ invocation).

Yours, Junxiao


On Wed, May 7, 2014 at 11:29 AM, Ashlesh Gawande (agawande) <
agawande at memphis.edu> wrote:

>  ?I have 1.55.0, installed it myself after removing older versions.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140507/2d461927/attachment.html>

From shijunxiao at email.arizona.edu  Wed May  7 13:12:18 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 7 May 2014 13:12:18 -0700
Subject: [Nfd-dev] Fwd: ndn-cxx error on CentOs
In-Reply-To: <1399489190861.83144@memphis.edu>
References: <CAOFH+OZag7C9sYXNQ3XfGT4KWwOUBca3DSFq0jWF7C54+Hg8JA@mail.gmail.com>
	<1399489190861.83144@memphis.edu>
Message-ID: <CAOFH+OazOK0Wzbyce3UZaJXQX3t9BO88fLqOn57FUewGrBM8wQ@mail.gmail.com>

Hi Ashlesh

The log snippet shows that libboost_filesystem-mt.so is picked. It is
likely a symbolic link to libboost_filesystem-mt.so.5 which is part of
Boost 1.41.
Please delete all Boost versions prior to 1.55, including libraries and
headers.

Alternatively, you may install Boost 1.55 libraries to a different path,
and supply a "--boost-libs" option to waf configure.

Yours, Junxiao

----------------------------------------
Checking boost libs
Found the boost path in /usr/lib with the libraries:
    /usr/lib/libboost_filesystem-mt.so
    /usr/lib/libboost_filesystem-mt.so.5
    /usr/lib/libboost_filesystem.a
    /usr/lib/libboost_filesystem.so
    /usr/lib/libboost_filesystem.so.1.55.0
    /usr/lib/libboost_filesystem.so.5
Trying pattern boost_filesystem(-gcc[0-9]{0,3})+(-1_55)+
Trying pattern boost_filesystem(-1_55)+
Trying pattern boost_filesystem(-1_55)+
Trying pattern boost_filesystem(-gcc[0-9]{0,3})+
Trying pattern boost_filesystem
Found boost lib libboost_filesystem-mt.so
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140507/37af52a0/attachment.html>

From lanwang at memphis.edu  Thu May  8 08:15:19 2014
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Thu, 8 May 2014 15:15:19 +0000
Subject: [Nfd-dev] Fwd: ndn-cxx error on CentOs
In-Reply-To: <CAOFH+OazOK0Wzbyce3UZaJXQX3t9BO88fLqOn57FUewGrBM8wQ@mail.gmail.com>
References: <CAOFH+OZag7C9sYXNQ3XfGT4KWwOUBca3DSFq0jWF7C54+Hg8JA@mail.gmail.com>
	<1399489190861.83144@memphis.edu>
	<CAOFH+OazOK0Wzbyce3UZaJXQX3t9BO88fLqOn57FUewGrBM8wQ@mail.gmail.com>
Message-ID: <3941388E-2DFF-45B1-838D-1967FE0D9A8A@memphis.edu>

Ashlesh,

I think it's best that we have only the minimum required version of boost (1.48?) installed on the machine.   Hoque has modified the NLSR code to make it work with boost 1.48 so that should not be a problem.

Lan
On May 7, 2014, at 3:12 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
 wrote:

Hi Ashlesh

The log snippet shows that libboost_filesystem-mt.so is picked. It is likely a symbolic link to libboost_filesystem-mt.so.5 which is part of Boost 1.41.
Please delete all Boost versions prior to 1.55, including libraries and headers.

Alternatively, you may install Boost 1.55 libraries to a different path, and supply a "--boost-libs" option to waf configure.

Yours, Junxiao

----------------------------------------
Checking boost libs
Found the boost path in /usr/lib with the libraries:
    /usr/lib/libboost_filesystem-mt.so
    /usr/lib/libboost_filesystem-mt.so.5
    /usr/lib/libboost_filesystem.a
    /usr/lib/libboost_filesystem.so
    /usr/lib/libboost_filesystem.so.1.55.0
    /usr/lib/libboost_filesystem.so.5
Trying pattern boost_filesystem(-gcc[0-9]{0,3})+(-1_55)+
Trying pattern boost_filesystem(-1_55)+
Trying pattern boost_filesystem(-1_55)+
Trying pattern boost_filesystem(-gcc[0-9]{0,3})+
Trying pattern boost_filesystem
Found boost lib libboost_filesystem-mt.so

_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto: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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140508/95452965/attachment.html>

From alexander.afanasyev at ucla.edu  Thu May  8 09:20:52 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Thu, 8 May 2014 09:20:52 -0700
Subject: [Nfd-dev] ndn-cxx error on CentOs
In-Reply-To: <3941388E-2DFF-45B1-838D-1967FE0D9A8A@memphis.edu>
References: <CAOFH+OZag7C9sYXNQ3XfGT4KWwOUBca3DSFq0jWF7C54+Hg8JA@mail.gmail.com>
	<1399489190861.83144@memphis.edu>
	<CAOFH+OazOK0Wzbyce3UZaJXQX3t9BO88fLqOn57FUewGrBM8wQ@mail.gmail.com>
	<3941388E-2DFF-45B1-838D-1967FE0D9A8A@memphis.edu>
Message-ID: <52DE0C24-0A7B-49E0-BBD5-95C04146C7EA@ucla.edu>

If installing boost from source, there is no point of installing old version.

On CentOS, boost has to be installed from source (until we do some magic with binaries), since CentOS provides extremely old version.

---
Alex

On May 8, 2014, at 8:15 AM, Lan Wang (lanwang) <lanwang at memphis.edu> wrote:

> Ashlesh,
> 
> I think it's best that we have only the minimum required version of boost (1.48?) installed on the machine.   Hoque has modified the NLSR code to make it work with boost 1.48 so that should not be a problem.
> 
> Lan
> On May 7, 2014, at 3:12 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
>  wrote:
> 
>> Hi Ashlesh
>> 
>> The log snippet shows that libboost_filesystem-mt.so is picked. It is likely a symbolic link to libboost_filesystem-mt.so.5 which is part of Boost 1.41.
>> Please delete all Boost versions prior to 1.55, including libraries and headers.
>> 
>> Alternatively, you may install Boost 1.55 libraries to a different path, and supply a "--boost-libs" option to waf configure.
>> 
>> Yours, Junxiao
>> 
>> ----------------------------------------
>> Checking boost libs
>> Found the boost path in /usr/lib with the libraries:
>>     /usr/lib/libboost_filesystem-mt.so
>>     /usr/lib/libboost_filesystem-mt.so.5
>>     /usr/lib/libboost_filesystem.a
>>     /usr/lib/libboost_filesystem.so
>>     /usr/lib/libboost_filesystem.so.1.55.0
>>     /usr/lib/libboost_filesystem.so.5
>> Trying pattern boost_filesystem(-gcc[0-9]{0,3})+(-1_55)+
>> Trying pattern boost_filesystem(-1_55)+
>> Trying pattern boost_filesystem(-1_55)+
>> Trying pattern boost_filesystem(-gcc[0-9]{0,3})+
>> Trying pattern boost_filesystem
>> Found boost lib libboost_filesystem-mt.so
>> 
>> _______________________________________________
>> 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140508/a8d2c3a8/attachment.html>

From lanwang at memphis.edu  Thu May  8 09:48:37 2014
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Thu, 8 May 2014 16:48:37 +0000
Subject: [Nfd-dev] ndn-cxx error on CentOs
In-Reply-To: <52DE0C24-0A7B-49E0-BBD5-95C04146C7EA@ucla.edu>
References: <CAOFH+OZag7C9sYXNQ3XfGT4KWwOUBca3DSFq0jWF7C54+Hg8JA@mail.gmail.com>
	<1399489190861.83144@memphis.edu>
	<CAOFH+OazOK0Wzbyce3UZaJXQX3t9BO88fLqOn57FUewGrBM8wQ@mail.gmail.com>
	<3941388E-2DFF-45B1-838D-1967FE0D9A8A@memphis.edu>
	<52DE0C24-0A7B-49E0-BBD5-95C04146C7EA@ucla.edu>
Message-ID: <72458705-DA2D-4183-9CDB-1D3CE088670E@memphis.edu>

I see.  I was thinking from the viewpoint of testing since this is the purpose of this exercise (whether the code works with the minimum boost version required).  If it is difficult to do this on CentOS, then of course higher version is fine.

Lan
On May 8, 2014, at 11:20 AM, Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
 wrote:

If installing boost from source, there is no point of installing old version.

On CentOS, boost has to be installed from source (until we do some magic with binaries), since CentOS provides extremely old version.

---
Alex

On May 8, 2014, at 8:15 AM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

Ashlesh,

I think it's best that we have only the minimum required version of boost (1.48?) installed on the machine.   Hoque has modified the NLSR code to make it work with boost 1.48 so that should not be a problem.

Lan
On May 7, 2014, at 3:12 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
 wrote:

Hi Ashlesh

The log snippet shows that libboost_filesystem-mt.so is picked. It is likely a symbolic link to libboost_filesystem-mt.so.5 which is part of Boost 1.41.
Please delete all Boost versions prior to 1.55, including libraries and headers.

Alternatively, you may install Boost 1.55 libraries to a different path, and supply a "--boost-libs" option to waf configure.

Yours, Junxiao

----------------------------------------
Checking boost libs
Found the boost path in /usr/lib with the libraries:
    /usr/lib/libboost_filesystem-mt.so
    /usr/lib/libboost_filesystem-mt.so.5
    /usr/lib/libboost_filesystem.a
    /usr/lib/libboost_filesystem.so
    /usr/lib/libboost_filesystem.so.1.55.0
    /usr/lib/libboost_filesystem.so.5
Trying pattern boost_filesystem(-gcc[0-9]{0,3})+(-1_55)+
Trying pattern boost_filesystem(-1_55)+
Trying pattern boost_filesystem(-1_55)+
Trying pattern boost_filesystem(-gcc[0-9]{0,3})+
Trying pattern boost_filesystem
Found boost lib libboost_filesystem-mt.so

_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto: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<mailto: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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140508/ac761f17/attachment.html>

From alexander.afanasyev at ucla.edu  Thu May  8 10:20:47 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Thu, 8 May 2014 10:20:47 -0700
Subject: [Nfd-dev] ndn-cxx error on CentOs
In-Reply-To: <1399568563012.7101@memphis.edu>
References: <CAOFH+OZag7C9sYXNQ3XfGT4KWwOUBca3DSFq0jWF7C54+Hg8JA@mail.gmail.com>
	<1399489190861.83144@memphis.edu>
	<CAOFH+OazOK0Wzbyce3UZaJXQX3t9BO88fLqOn57FUewGrBM8wQ@mail.gmail.com>
	<3941388E-2DFF-45B1-838D-1967FE0D9A8A@memphis.edu>
	<52DE0C24-0A7B-49E0-BBD5-95C04146C7EA@ucla.edu>
	<72458705-DA2D-4183-9CDB-1D3CE088670E@memphis.edu>
	<1399568563012.7101@memphis.edu>
Message-ID: <83517110-12D9-463A-8D57-D80A1035DF55@ucla.edu>

If you installed library in /usr/local (default), then you need to adjust PKG_CONFIG_PATH (check examples in NFD docs).

---
Alex

> On May 8, 2014, at 10:02 AM, "Ashlesh Gawande (agawande)" <agawande at memphis.edu> wrote:
> 
> I did a clean install of boost 1.55.0 and ndn-cxx is now installed on centOS, but now NFD is not detecting libndn-cxx.
> 
> Ashlesh
>  
> From: Lan Wang (lanwang)
> Sent: Thursday, May 08, 2014 11:48 AM
> To: Alex Afanasyev
> Cc: Junxiao Shi; Ashlesh Gawande (agawande); <nfd-dev at lists.cs.ucla.edu>
> Subject: Re: [Nfd-dev] ndn-cxx error on CentOs
>  
> I see.  I was thinking from the viewpoint of testing since this is the purpose of this exercise (whether the code works with the minimum boost version required).  If it is difficult to do this on CentOS, then of course higher version is fine.
> 
> Lan
> On May 8, 2014, at 11:20 AM, Alex Afanasyev <alexander.afanasyev at ucla.edu>
>  wrote:
> 
>> If installing boost from source, there is no point of installing old version.
>> 
>> On CentOS, boost has to be installed from source (until we do some magic with binaries), since CentOS provides extremely old version.
>> 
>> ---
>> Alex
>> 
>>> On May 8, 2014, at 8:15 AM, Lan Wang (lanwang) <lanwang at memphis.edu> wrote:
>>> 
>>> Ashlesh,
>>> 
>>> I think it's best that we have only the minimum required version of boost (1.48?) installed on the machine.   Hoque has modified the NLSR code to make it work with boost 1.48 so that should not be a problem.
>>> 
>>> Lan
>>> On May 7, 2014, at 3:12 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
>>>  wrote:
>>> 
>>>> Hi Ashlesh
>>>> 
>>>> The log snippet shows that libboost_filesystem-mt.so is picked. It is likely a symbolic link to libboost_filesystem-mt.so.5 which is part of Boost 1.41.
>>>> Please delete all Boost versions prior to 1.55, including libraries and headers.
>>>> 
>>>> Alternatively, you may install Boost 1.55 libraries to a different path, and supply a "--boost-libs" option to waf configure.
>>>> 
>>>> Yours, Junxiao
>>>> 
>>>> ----------------------------------------
>>>> Checking boost libs
>>>> Found the boost path in /usr/lib with the libraries:
>>>>     /usr/lib/libboost_filesystem-mt.so
>>>>     /usr/lib/libboost_filesystem-mt.so.5
>>>>     /usr/lib/libboost_filesystem.a
>>>>     /usr/lib/libboost_filesystem.so
>>>>     /usr/lib/libboost_filesystem.so.1.55.0
>>>>     /usr/lib/libboost_filesystem.so.5
>>>> Trying pattern boost_filesystem(-gcc[0-9]{0,3})+(-1_55)+
>>>> Trying pattern boost_filesystem(-1_55)+
>>>> Trying pattern boost_filesystem(-1_55)+
>>>> Trying pattern boost_filesystem(-gcc[0-9]{0,3})+
>>>> Trying pattern boost_filesystem
>>>> Found boost lib libboost_filesystem-mt.so
>>>> 
>>>> _______________________________________________
>>>> 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140508/e293dddf/attachment.html>

From agawande at memphis.edu  Thu May  8 10:02:36 2014
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Thu, 8 May 2014 17:02:36 +0000
Subject: [Nfd-dev] ndn-cxx error on CentOs
In-Reply-To: <72458705-DA2D-4183-9CDB-1D3CE088670E@memphis.edu>
References: <CAOFH+OZag7C9sYXNQ3XfGT4KWwOUBca3DSFq0jWF7C54+Hg8JA@mail.gmail.com>
	<1399489190861.83144@memphis.edu>
	<CAOFH+OazOK0Wzbyce3UZaJXQX3t9BO88fLqOn57FUewGrBM8wQ@mail.gmail.com>
	<3941388E-2DFF-45B1-838D-1967FE0D9A8A@memphis.edu>
	<52DE0C24-0A7B-49E0-BBD5-95C04146C7EA@ucla.edu>,
	<72458705-DA2D-4183-9CDB-1D3CE088670E@memphis.edu>
Message-ID: <1399568563012.7101@memphis.edu>

I did a clean install of boost 1.55.0 and ndn-cxx is now installed on centOS, but now NFD is not detecting libndn-cxx.


Ashlesh

________________________________
From: Lan Wang (lanwang)
Sent: Thursday, May 08, 2014 11:48 AM
To: Alex Afanasyev
Cc: Junxiao Shi; Ashlesh Gawande (agawande); <nfd-dev at lists.cs.ucla.edu>
Subject: Re: [Nfd-dev] ndn-cxx error on CentOs

I see.  I was thinking from the viewpoint of testing since this is the purpose of this exercise (whether the code works with the minimum boost version required).  If it is difficult to do this on CentOS, then of course higher version is fine.

Lan
On May 8, 2014, at 11:20 AM, Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
 wrote:

If installing boost from source, there is no point of installing old version.

On CentOS, boost has to be installed from source (until we do some magic with binaries), since CentOS provides extremely old version.

---
Alex

On May 8, 2014, at 8:15 AM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

Ashlesh,

I think it's best that we have only the minimum required version of boost (1.48?) installed on the machine.   Hoque has modified the NLSR code to make it work with boost 1.48 so that should not be a problem.

Lan
On May 7, 2014, at 3:12 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
 wrote:

Hi Ashlesh

The log snippet shows that libboost_filesystem-mt.so is picked. It is likely a symbolic link to libboost_filesystem-mt.so.5 which is part of Boost 1.41.
Please delete all Boost versions prior to 1.55, including libraries and headers.

Alternatively, you may install Boost 1.55 libraries to a different path, and supply a "--boost-libs" option to waf configure.

Yours, Junxiao

----------------------------------------
Checking boost libs
Found the boost path in /usr/lib with the libraries:
    /usr/lib/libboost_filesystem-mt.so
    /usr/lib/libboost_filesystem-mt.so.5
    /usr/lib/libboost_filesystem.a
    /usr/lib/libboost_filesystem.so
    /usr/lib/libboost_filesystem.so.1.55.0
    /usr/lib/libboost_filesystem.so.5
Trying pattern boost_filesystem(-gcc[0-9]{0,3})+(-1_55)+
Trying pattern boost_filesystem(-1_55)+
Trying pattern boost_filesystem(-1_55)+
Trying pattern boost_filesystem(-gcc[0-9]{0,3})+
Trying pattern boost_filesystem
Found boost lib libboost_filesystem-mt.so

_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto: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<mailto: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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140508/22a6af1a/attachment.html>

From alexander.afanasyev at ucla.edu  Mon May 12 15:01:18 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Mon, 12 May 2014 15:01:18 -0700
Subject: [Nfd-dev] NFD version 0.1.0 released
Message-ID: <7B1C4F43-3970-405F-B508-461338F537F2@ucla.edu>

Hi everybody,

We are pleased to formally announce release of version 0.1.0 of our new NDN Forwarding Daemon.

I would like to thank you everybody for the essential comments and initial testing of the release candidate.

Since the release candidate we did several improvements and bug fixes, as well provided updated documentation.  The documentation is still not as we would wanted to have and we are setting the goal of adding more detailed description of the NFD internals for version 0.2.x, which we plan to release some time in June.

NFD overview and release notes are available online on NFD's homepage: http://named-data.net/doc/NFD/0.1.0/

Binary release
--------------

As of release 0.1.0, we are providing NFD binaries for the supported platforms, which are the preferred installation method of NFD:

- Ubuntu 12.04, 13.10, and 14.04: http://named-data.net/doc/NFD/0.1.0/FAQ.html#how-to-start-using-ndn-ppa-repository-on-ubuntu-linux
- OSX 10.8, 10.9 with MacPorts: http://named-data.net/doc/NFD/0.1.0/FAQ.html#how-to-start-using-ndn-macports-repository-on-osx

Next releases would include support for other platforms.  Please send us feedback on the platforms you're using, so we can prioritize our goals.  We would also appreciate if someone can provide help with packaging the current NFD release for other platforms.

Besides simplicity of installation, the binary release includes automatic initial configuration and platform-specific tools to automatically start NFD and related daemons.  In particular, on OSX NFD is controlled using launchd and on Ubuntu using upstart mechanisms.  In both cases, `nfd-start` and `nfd-stop` scripts are convenience wrappers for launchd and upstart.  For more information refer to https://github.com/named-data/NFD/tree/master/contrib/osx-launchd and https://github.com/named-data/NFD/tree/master/contrib/upstart.

Source releases
---------------

The source code and source-code installation instructions are always available on NFD's homepage:

- Getting Started with NFD:  http://named-data.net/doc/NFD/0.1.0/getting-started.html
- Github NFD repository:  https://github.com/named-data/NFD

Additional information
----------------------

- NFD Wiki: http://redmine.named-data.net/projects/nfd/wiki/
- Feature requests and bug reports are welcome on our NDN Redmine: http://redmine.named-data.net/projects/nfd

Besides officially supported platforms, NFD is known to work on: Fedora 20, CentOS 6, Raspberry Pi, OpenWRT, FreeBSD 10.0, and several other platforms.  We are soliciting help with documenting common problems / pitfalls in installing/using NFD on different platforms on NFD WiKi (http://redmine.named-data.net/projects/nfd/wiki/Wiki#Installation-experiences-for-selected-platforms).

=========================================================================================

Features in version 0.1.0
-------------------------

- Packet Format

 + `NDN-TLV <http://named-data.net/doc/ndn-tlv/>`_
 + LocalControlHeader, to allow apps to set outgoing face and learn incoming face.

- Faces

 + Unix stream socket
 + UDP unicast
 + UDP multicast
 + TCP
 + Ethernet, currently without fragmentation.

   .. note::
        Ethernet support will not work properly on Linux kernels with TPACKET_V3 flexible
        buffer implementation (>= 3.2.0) and libpcap >= 1.5.0 (e.g., Ubuntu Linux 14.04).
        Refer to `Issue 1551 <http://redmine.named-data.net/issues/1511>`_ for more
        detail and implementation progress.

- Management

 + Use of signed Interests as commands, with authentication and authorization.
 + Face management
 + FIB management
 + Per-namespace strategy selection
 + NFD status publishing
 + Notification to authorized apps of internal events, including Face creation and destruction.

- Tables and forwarding pipelines support most Interest/Data processing, including
 selectors.

- RIB Management that runs as a separate process, ``nrd``.  It supports basic prefix
 registration by applications, but no flags yet.

- Strategies

 + ``broadcast``
 + ``best-route``
 + ``ncc``: based on ccnx 0.7 for experimentation
 + ``client-control``: authorized application can directly control Interest forwarding

- Name-based scoping

 + ``/localhost``: communication only within localhost using "local" Faces
   (UnixStreamFace, LocalTcpFace).  NFD will strictly enforce this scope for Interests
   and Data packets
 + ``/localhop``: one-hop communication (e.g., if at least one incoming or outgoing Face
   in PIT entry is non-local, the Interest cannot be forwarded to any non-local Face)

- Support configuration file, which is in the Boost INFO format.

- Applications

 + Tools to discover hubs on NDN testbed.
 + peek/poke and traffic generators for testing and debugging.
 + ``nfdc``, a command-line tool to configure NFD.
 + ``nfd-status``, a command-line tool to query NFD status.
 + ``nfd-status-http-server``, which reads the NFD status and publishes over HTTP.

---
NFD Team


From alexander.afanasyev at ucla.edu  Thu May 15 10:49:45 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Thu, 15 May 2014 10:49:45 -0700
Subject: [Nfd-dev] Notification of upcoming branch changes in ndn-cxx repo
Message-ID: <C1B56F3C-8162-4608-9A78-FE9A39DA6D8F@ucla.edu>

Hi guys,

After we have released NFD, I have updated branches (master -> v0.1-dev for urgent bug-fixes, v0.2-dev -> master to continue development).

I haven't made similar update with ndn-cxx repo and this email is just warn you about this change.  There are a few small API changes that shouldn't really affect application, but which will affect NFD compilation.  My plan is to do the update of ndn-cxx branches as soon as pending NFD commits are ready to be submitted (specifically this one: http://gerrit.named-data.net/#/c/820/), so the master branch of NFD will compile against the master branch of ndn-cxx without problems.

---
Alex


From bzhang at cs.arizona.edu  Fri May 16 08:01:51 2014
From: bzhang at cs.arizona.edu (Beichuan Zhang)
Date: Fri, 16 May 2014 08:01:51 -0700
Subject: [Nfd-dev] nfd documentation
Message-ID: <82E2671C-7225-48FC-89A3-C5F2008E723D@cs.arizona.edu>

Dear All,

After the internal release of v.0.1 of NFD, we?re now working on the next release v0.2, which will be publicized to the ICN community in general. The most critical thing needed is better documentation, and again, we plan to do it with a team effort. 

We?ve created a separate repository for an NFD Developer?s Guide: git at git.irl.cs.ucla.edu:papers/nfd-docs.git (if you don?t have access, please contact Alexander Afanasyev <alexander.afanasyev at ucla.edu>). This document explains the internals of the NFD, and the target readers are people who may want to extend and improve NFD.  Each section corresponds to a module in NFD, and its content should include (1) the design and structure of the module, (2) the interaction between other modules, (3) explanation of major components of this module and their interactions, (4) figures to help understand the text. The hope is that after reading this guide, other developers would have good ideas of how NFD was designed and implemented, which will help them to plan any changes. 

Right now you?ll only find section titles in the repository. We will assign the writing of each section to the main developer who wrote the code, and you?ll soon receive Redmine emails about the assignment. The deadline is June 8, after which we?ll have one week to do integration. As always, please let us know ASAP if there?s any problem.

Thanks!

Beichuan


From lanwang at memphis.edu  Fri May 16 09:03:45 2014
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Fri, 16 May 2014 16:03:45 +0000
Subject: [Nfd-dev] Fwd: [NFD - Task #1325] Generate FIB updates
References: <redmine.journal-2921.20140516110454.a174d44197565b01@named-data.net>
Message-ID: <688C5DC6-2C05-4790-A92C-64160D704EE1@memphis.edu>



Begin forwarded message:

From: <redmine-noreply at named-data.net<mailto:redmine-noreply at named-data.net>>
Subject: [NFD - Task #1325] Generate FIB updates
Date: May 16, 2014 6:04:54 AM CDT
To: Undisclosed recipients:;

Issue #1325 has been updated by Lan Wang.

Vince:

The statement "CAPTURE: indicates that no shorter prefix can be used; overrides CHILD_INHERIT. This flag applies on the prefix: if any route of a prefix has this flag, the prefix will have this flag." means just for that particular prefix, not longer prefixes. The prefix (e.g., /ndn/edu/memphis) can have multiple routes. If any of those routes has this flag, the prefix has this flag set.

For your question "Does that not mean if an entry has its CAPTURE flag set, then its children would also have their capture flag set?", I think the answer is no. What Obaid said is the following: If an entry A has its CAPTURE flag set, the children cannot use the nexthop of A's ancestors. This is different from setting a child's capture flag, which means that child cannot use its own ancestors' nexthops (including A's).

________________________________

For everyone: I would like to get comments on two issues and reach an agreement:

  1.  do you think this is correct for the CAPTURE flag: "This flag applies on the prefix: if any route of a prefix has this flag, the prefix will have this flag."? In contrast, the INHERIT flag applies only to (prefix, nexthop). Do you think this is the correct behavior for INHERIT?

  2.  do you think the CAPTURE flag on prefix A should block all A's children from using A's ancestors' nexthops?

Lan

________________________________
Task #1325: Generate FIB updates<http://redmine.named-data.net/issues/1325#change-2921>

  *   Author: Syed Amin
  *   Status: New
  *   Priority: Normal
  *   Assignee: Vince Lehman
  *   Category: RIB (NRD)
  *   Target version: v0.2

Traverse the RIB Tree and generate fib updates according to the flags.

________________________________

You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here:http://redmine.named-data.net/my/account

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140516/86864408/attachment.html>

From shijunxiao at email.arizona.edu  Fri May 16 09:57:00 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 16 May 2014 09:57:00 -0700
Subject: [Nfd-dev] Jenkins scheduled maintenance
Message-ID: <CAOFH+OZaxDsxaGSmtFuUa4QE6pnRhStzxq3xNfcbPv7HjS2Gng@mail.gmail.com>

Hi NFD developers

The physical machine hosting Jenkins has a scheduled hardware inspection
since May 16 19:40 UTC until May 17 02:00 UTC.
Jenkins will be down during this time.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140516/cbada26f/attachment.html>

From shijunxiao at email.arizona.edu  Fri May 16 23:51:50 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 16 May 2014 23:51:50 -0700
Subject: [Nfd-dev] Jenkins scheduled maintenance
In-Reply-To: <CAOFH+OZaxDsxaGSmtFuUa4QE6pnRhStzxq3xNfcbPv7HjS2Gng@mail.gmail.com>
References: <CAOFH+OZaxDsxaGSmtFuUa4QE6pnRhStzxq3xNfcbPv7HjS2Gng@mail.gmail.com>
Message-ID: <CAOFH+OZ43G_=PFJAz5K0AOU96niPuTk72O+cYJPWksE09B+gXQ@mail.gmail.com>

Hi NFD developers

Hardware inspection is completed. Jenkins is now up.

Yours, Junxiao


On Fri, May 16, 2014 at 9:57 AM, Junxiao Shi
<shijunxiao at email.arizona.edu>wrote:

> Hi NFD developers
>
> The physical machine hosting Jenkins has a scheduled hardware inspection
> since May 16 19:40 UTC until May 17 02:00 UTC.
> Jenkins will be down during this time.
>
> Yours, Junxiao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140516/a86150bd/attachment.html>

From jburke at remap.ucla.edu  Sun May 18 09:17:50 2014
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Sun, 18 May 2014 16:17:50 +0000
Subject: [Nfd-dev] Interest scoping and broadcast channels
In-Reply-To: <CF9D6142.142A99%jburke@remap.ucla.edu>
Message-ID: <CF9E2B28.142B2D%jburke@remap.ucla.edu>


Hi folks,

Can you please suggest how to handle the following use case:

Consider a low-power device communicating on a broadcast channel.   If we want the device to "hear" Data in a given prefix that is transmitted on the broadcast channel but not itself transmit an interest for it, how can we do that?   Put another way, will/can a locally-scoped interest be matched against Data packets arriving on a non-local Face?

More on the use case:

On a low-power sensor node we want to delay responding to a general prefix if another node has already responded.  We can introduce (for example) a random delay and then check if some other node has answered; the most NDN-like way to check seems to be to have an outstanding Interest for the prefix locally that is compared with Data coming in over the broadcast media.

Thanks,
Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140518/e3d73f3a/attachment.html>

From shijunxiao at email.arizona.edu  Sun May 18 12:20:56 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sun, 18 May 2014 12:20:56 -0700
Subject: [Nfd-dev] Interest scoping and broadcast channels
In-Reply-To: <CF9E2B28.142B2D%jburke@remap.ucla.edu>
References: <CF9D6142.142A99%jburke@remap.ucla.edu>
	<CF9E2B28.142B2D%jburke@remap.ucla.edu>
Message-ID: <CAOFH+Ob55+DEwT2vd4F-gjJkMFdSoOOzuM3dK-mrvArahy9W+A@mail.gmail.com>

Hi Jeff

A locally-scoped Interest (with prefix ndn:/localhost) can never be
satisfied by a Data from a non-local face, because such Data would begin
with ndn:/localhost which could not be transmitted on a non-local face (and
will be dropped if received).

Multicast face has duplicate suppression capability. If both this host and
other hosts are answering with exactly same Data Name, and this host
doesn't care about the content from other host, this scenario can be well
handled by duplicate suppression. See Task 1282 for discussion on this
feature http://redmine.named-data.net/issues/1282

If this host needs to know the content from other host, use NFD's packet
capture feature. The packet capture feature allows a program to listen for
a subset of packets processed by NFD, with filters on face, direction, and
name prefix.
There is no Task for this feature yet. You may also use the workaround
designed by NLSR: express the Interest as soon as you receive it. Strategy
won't transmit it into the multicast face.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140518/1d628d1a/attachment.html>

From jburke at remap.ucla.edu  Sun May 18 12:55:44 2014
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Sun, 18 May 2014 19:55:44 +0000
Subject: [Nfd-dev] Interest scoping and broadcast channels
In-Reply-To: <CAOFH+Ob55+DEwT2vd4F-gjJkMFdSoOOzuM3dK-mrvArahy9W+A@mail.gmail.com>
Message-ID: <CF9E5ACA.142B7A%jburke@remap.ucla.edu>

Hi Junxiao,
Thanks for the quick reply. Comments below.
Jeff


From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Sun, 18 May 2014 12:20:56 -0700
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: "<nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Interest scoping and broadcast channels


Hi Jeff

A locally-scoped Interest (with prefix ndn:/localhost) can never be satisfied by a Data from a non-local face, because such Data would begin with ndn:/localhost which could not be transmitted on a non-local face (and will be dropped if received).

[jb] That's what I thought and it makes sense to me.  (Though, what is the relationship between the Scope selector<http://named-data.net/doc/ndn-tlv/interest.html#scope> in the TLV packet format and these names?  Couldn't one have the scope selector set without the corresponding name? Apologies if this is explained somewhere already ? a link may be needed to that explanation in the TLV packet format doc.)

Multicast face has duplicate suppression capability. If both this host and other hosts are answering with exactly same Data Name, and this host doesn't care about the content from other host, this scenario can be well handled by duplicate suppression. See Task 1282 for discussion on this feature http://redmine.named-data.net/issues/1282

[jb] They are answering the same prefix with different data objects, so it's a different situation.

If this host needs to know the content from other host, use NFD's packet capture feature. The packet capture feature allows a program to listen for a subset of packets processed by NFD, with filters on face, direction, and name prefix. There is no Task for this feature yet.

[jb] Ok, we'll keep an eye out for this.  While I figured that something like this was possible, I had previously come to the conclusion that it was better to preserve NDN semantics ? if it is Data that an application is interested in, wouldn't it be most NDN-like if it issued an Interest for it?     This sort of "parasitic Interest", which "listens" on a Face for data but doesn't propagate, seems useful in a variety of contexts having to do with low-bandwidth broadcast channels or power-constrained consumers.    The advantage is that the callback mechanism is exactly the same as what app developers would be used to, without having to descend into a different (packet capture) API.

You may also use the workaround designed by NLSR: express the Interest as soon as you receive it. Strategy won't transmit it into the multicast face.

[jb] Ok, makes sense. But this assumes that you hear the Interest and that it matches your request, right?   There are at least two cases where this isn't a good fit:  1) A lossy radio channel where you hear data from a nearby node more often than interests from a remote consumer closer to the other node ;  2) Let's say the parasitic consumer is interested in /home/devices/sensors but the external interest that generates data is /home/devices/sensors/foo or /home/devices... while it's doable, handling the matching logic in the application seems unnecessarily complicated instead of a passive or parasitic listening capability offered by the library and/or forwarder.




Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140518/32965c30/attachment.html>

From lanwang at memphis.edu  Wed May 21 12:04:43 2014
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Wed, 21 May 2014 19:04:43 +0000
Subject: [Nfd-dev] New results
In-Reply-To: <1400698540885.4431@memphis.edu>
References: <1wfcbo36iud0ptgobsxex87h.1400528855540@email.android.com>
	<1400530152257.71376@memphis.edu>,
	<7221E548-973E-4CA0-9639-3DAA088AC23E@memphis.edu>
	<1400608575306.66491@memphis.edu>,
	<CBC89AF5-1950-43DD-8792-53A7AC9C2987@memphis.edu>
	<1400698540885.4431@memphis.edu>
Message-ID: <676C97C7-D795-418C-99D1-EA6E0780306C@memphis.edu>

Hi Ashlesh,

Thank you for the new testing results.  Since others don't have access to our wiki, I'm pasting the results in this email.  Please keep the test running and see if the routes remain in the FIB.

Lan
On May 21, 2014, at 1:55 PM, "Ashlesh Gawande (agawande)" <agawande at memphis.edu<mailto:agawande at memphis.edu>>
 wrote:

Professor

The new network is now made (under "test2").
Also, I have written how my script works.

https://netlab.cs.memphis.edu/wiki/NLSR/Home?

Ashlesh

May 21
Added Gemini, Altair, and Rigel to the previous network and observed FIBs.
[cid:2944AC24-F393-420A-9443-5EF640A446D2]

Writing FIBs in shorthand, to make them easier to read.

Nexthop#/Face/Cost

POLLUX

rigel 1/18/45,2/32/45,3/42/78

sol 1/18/25,2/32/25,3/42/58

altair 1/18/30,2/32/30,3/42/63

gemini 1/18/30,2/32/35,3/42/63

vesta 1/18/45,2/32/65,3/42/18

sirius 1/18/15,2/32/35,3/42/48

________________________________

VESTA

pollux 1/8/45,2/6/18

rigel 1/8/60,2/6/63

sol 1/8/40,2/6/43

altair 1/8/45,2/6/48

gemini 1/8/45,2/6/48

sirius 1/8/30,2/6/33

________________________________

SOL

pollux 1/23/25,2/101/40,3/26/25

rigel 1/70/20

altair 1/106/5

gemini 1/23/88,2/101/10,3/26/25

vesta 1/23/43,2/101/55,3/26/40

sirius 1/23/73,2/101/25,3/26/10

________________________________

SIRIUS

pollux 1/18/35,2/87/50,3/6/15,4/42/48

rigel 1/18/30,2/87/45,3/6/60,4/42/93

sol 1/18/10,2/87/25,3/6/40,4/42/73

altair 1/18/15,2/87/30,3/6/45,4/42/78

gemini 1/18/20,2/87/15,3/6/50,4/42/83

vesta 1/18/53,2/87/68,3/6/33,4/42/30

________________________________

GEMINI

pollux 1/9/30,2/7/35

rigel 1/9/45,2/7/30

sol 1/9/25,2/7/10

altair 1/9/30,2/7/15

vesta 1/9/45,2/7/50

sirius 1/9/15,2/7/20

________________________________

ALTAIR

pollux 1/9/30,2/7/35

rigel 1/9/45,2/7/30

sol 1/9/25,2/7/10

altair 1/9/30,2/7/15

vesta 1/9/45,2/7/50

sirius 1/9/15,2/7/20

________________________________

RIGEL

pollux 1/10/45

sol 1/10/20

altair 1/10/25

gemini 1/10/30

vesta 1/10/60

sirius 1/10/30

________________________________
________________________________

Bringing down Sirius and observing the FIBs:

[cid:758BA073-94CE-48D5-9247-AC4328BAFADF]

POLLUX

rigel 1/32/45

altair 1/32/30

gemini 1/32/35

sol 1/32/25

vesta 1/42/18

________________________________

VESTA

rigel 1/6/63

altair 1/6/48

gemini 1/6/53

sol 1/6/43

pollux 1/6/18

________________________________

SOL

rigel 1/70/20

altair 1/106/5

gemini 1/101/10

vesta 1/23/43

pollux 1/23/25

________________________________

GEMINI

rigel 1/7/30

altair 1/7/15

pollux 1/7/35

sol 1/7/10

vesta 1/7/53

________________________________

ALTAIR

rigel 1/18/25

gemini 1/18/15

pollux 1/18/30

sol 1/18/5

vesta 1/18/48

________________________________

RIGEL

altair 1/10/25

gemini 1/10/30

pollux 1/10/45

sol 1/10/20

vesta 1/10/63

________________________________
________________________________

NLSR was restarted on Sirius and FIBs were same as above (hence successful recovery).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140521/85b67e95/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2z5smlk.jpg
Type: image/png
Size: 116771 bytes
Desc: 2z5smlk.jpg
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140521/85b67e95/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 24mz4o7.jpg
Type: image/png
Size: 92076 bytes
Desc: 24mz4o7.jpg
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140521/85b67e95/attachment-0001.png>

From jburke at remap.UCLA.EDU  Fri May 23 23:19:40 2014
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Sat, 24 May 2014 06:19:40 +0000
Subject: [Nfd-dev] Change to segmenting and versioning conventions?
Message-ID: <CFA58803.144130%jburke@remap.ucla.edu>

Hi,

AlexA mentioned today that the segmenting and versioning conventions have changed in ndn-cxx (and thus nfd), and no longer have the preceding tag...

Could someone provide a pointer to the new convention documentation and explain the reasoning behind removing the tag?  [If this is the case, I'm not sure it's a good idea - one advantage of the tag is it provides explicit indication to an application that it is accessing segmented or versioned content, rather than relying on a priori understanding of the content namespace....]

Thanks,
Jeff

ps.  Would be great to get a list of other proposed changes to consider and discuss, if there are any...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140524/7a74416c/attachment.html>

From shijunxiao at email.arizona.edu  Fri May 23 23:44:54 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sat, 24 May 2014 14:44:54 +0800
Subject: [Nfd-dev] Change to segmenting and versioning conventions?
In-Reply-To: <CFA58803.144130%jburke@remap.ucla.edu>
References: <CFA58803.144130%jburke@remap.ucla.edu>
Message-ID: <CAOFH+OaFxthuB8QEzTfV0JK5htjyaqZwHC9w4WOK3p1AZoFRyg@mail.gmail.com>

Hi Jeff

Applications are allowed to use any number encoding.


NDN-TLV 0.2 spec defines three component
types<http://named-data.net/doc/NDN-TLV/0.2/name.html>:
NameComponent, NumberComponent, ImplicitSha256DigestComponent.

Both version number and segment number should use NumberComponent.
If a Data Name ends with two NumberComponents, it can be assumed versioned
and segmented, unless application protocol defines something else.
If a Data Name ends with one NumberComponent, it can be assumed segmented,
unless application protocol defines something else (eg. in
NotificationStream<http://redmine.named-data.net/projects/nfd/wiki/Notification>,
the NumberComponent is a sequence number).

ndn-cxx 0.1.0 implements NDN-TLV 0.1, so NumberComponent is encoded as
NameComponent.
NumberComponent and ImplicitSha256DigestComponent types will be implemented
in Task 1640 <http://redmine.named-data.net/issues/1640>.

Yours, Junxiao
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140524/ea94ef91/attachment.html>

From jburke at remap.ucla.edu  Fri May 23 23:51:35 2014
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Sat, 24 May 2014 06:51:35 +0000
Subject: [Nfd-dev] Change to segmenting and versioning conventions?
In-Reply-To: <CAOFH+OaFxthuB8QEzTfV0JK5htjyaqZwHC9w4WOK3p1AZoFRyg@mail.gmail.com>
Message-ID: <CFA58E82.144198%jburke@remap.ucla.edu>


Hi Junxiao,

Thanks for the explanation.   Both the change to implicit (rather than explicit) segments and versioning and the addition of type tags for name components are significant conceptual changes.  It seems like these should be discussed further before they are implemented; I'll ask Lixia and Beichuan.   Is there some type of design documentation that explains the motivation for the changes?

Thanks,
Jeff

From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Sat, 24 May 2014 14:44:54 +0800
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Change to segmenting and versioning conventions?

Hi Jeff

Applications are allowed to use any number encoding.


NDN-TLV 0.2 spec defines three component types<http://named-data.net/doc/NDN-TLV/0.2/name.html>: NameComponent, NumberComponent, ImplicitSha256DigestComponent.

Both version number and segment number should use NumberComponent.
If a Data Name ends with two NumberComponents, it can be assumed versioned and segmented, unless application protocol defines something else.
If a Data Name ends with one NumberComponent, it can be assumed segmented, unless application protocol defines something else (eg. in NotificationStream<http://redmine.named-data.net/projects/nfd/wiki/Notification>, the NumberComponent is a sequence number).

ndn-cxx 0.1.0 implements NDN-TLV 0.1, so NumberComponent is encoded as NameComponent.
NumberComponent and ImplicitSha256DigestComponent types will be implemented in Task 1640<http://redmine.named-data.net/issues/1640>.

Yours, Junxiao
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140524/886ca9fe/attachment.html>

From shijunxiao at email.arizona.edu  Tue May 27 02:07:43 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 27 May 2014 17:07:43 +0800
Subject: [Nfd-dev] Interest scoping and broadcast channels
In-Reply-To: <CF9E5ACA.142B7A%jburke@remap.ucla.edu>
References: <CAOFH+Ob55+DEwT2vd4F-gjJkMFdSoOOzuM3dK-mrvArahy9W+A@mail.gmail.com>
	<CF9E5ACA.142B7A%jburke@remap.ucla.edu>
Message-ID: <CAOFH+OZ6OGNd9y8X7yF3WxcxaeAH=rW-GBGmX7vW_LN5-Bv5sw@mail.gmail.com>

Hi Jeff

Parasitic Interest is possible in NFD 0.1.0.

To issue such an Interest:

   1. set client-control strategy on the namespace
   2. send the Interest, and specify application's own face as next-hop, so
   that this Interest won't be propagated
   3. to send a regular Interest to be propagated, specify the wireless
   multicast face


Yours, Junxiao

On Mon, May 19, 2014 at 3:55 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:

>  If this host needs to know the content from other host, use NFD's packet
> capture feature. The packet capture feature allows a program to listen for
> a subset of packets processed by NFD, with filters on face, direction, and
> name prefix. There is no Task for this feature yet.
> [jb] Ok, we'll keep an eye out for this.  While I figured that something
> like this was possible, I had previously come to the conclusion that it was
> better to preserve NDN semantics ? if it is Data that an application is
> interested in, wouldn't it be most NDN-like if it issued an Interest for
> it?     This sort of "parasitic Interest", which "listens" on a Face for
> data but doesn't propagate, seems useful in a variety of contexts having to
> do with low-bandwidth broadcast channels or power-constrained consumers.
>  The advantage is that the callback mechanism is exactly the same as what
> app developers would be used to, without having to descend into a different
> (packet capture) API.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140527/d6b9c555/attachment.html>

From shijunxiao at email.arizona.edu  Thu May 29 17:18:31 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 30 May 2014 08:18:31 +0800
Subject: [Nfd-dev] [ndn] NFD logging
In-Reply-To: <CALqQCKt+pavx1RmnNn=if0s6P3DZsGKxUj4xPybH8+8oT0aTfg@mail.gmail.com>
References: <CALqQCKt+pavx1RmnNn=if0s6P3DZsGKxUj4xPybH8+8oT0aTfg@mail.gmail.com>
Message-ID: <CAOFH+ObLiwCVX-qF6m9Lty4xTne-yVd59mABCp6G9JCT0xFjFQ@mail.gmail.com>

Hi Alex

NFD logs are written to stderr. You may redirect it to a file or pipe it to
a log rotator if needed.

Log levels are configurable in NFD configuration file
</usr/local/etc/nfd.conf>.

Yours, Junxiao
On May 30, 2014 8:10 AM, "Alex Horn" <nano at remap.ucla.edu> wrote:

> NFD team,
>
> where does NFD default log to ?
>
> It does occasionally crash, and I've put it in a restart loop so it's
> always working from user/application perspective.
>
> yet I'd also like to backup the logs as I do so, so we can (potentially)
> see why it's crashing.
>
> also, general logging questions - changing log level (debug/warn/error),
> and ability to set path... etc.
>
> Apologies if this is documented somewhere - you've done a pretty good job
> at documenting, but it's possible I've missed something.
>
> thanks !
>
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140530/e7ff18e3/attachment.html>

From lixia at CS.UCLA.EDU  Fri May 30 01:35:56 2014
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Fri, 30 May 2014 01:35:56 -0700
Subject: [Nfd-dev] nfd documentation
In-Reply-To: <82E2671C-7225-48FC-89A3-C5F2008E723D@cs.arizona.edu>
References: <82E2671C-7225-48FC-89A3-C5F2008E723D@cs.arizona.edu>
Message-ID: <5C29B5B4-039C-4956-9B46-518A53998A13@cs.ucla.edu>

folks, 

The writing assignment went out about 2 weeks ago, and there are about 10 days before the deadline.
Ilya seems the first one who started the doc writing effort on content store. Thanks Ilya!
Junxiao also started on forwarding table.
I expect everyone to start on their assignment soon, in order to meet our deadline of June 8th.

Lixia

On May 16, 2014, at 8:01 AM, Beichuan Zhang <bzhang at cs.arizona.edu> wrote:

> Dear All,
> 
> After the internal release of v.0.1 of NFD, we?re now working on the next release v0.2, which will be publicized to the ICN community in general. The most critical thing needed is better documentation, and again, we plan to do it with a team effort. 
> 
> We?ve created a separate repository for an NFD Developer?s Guide: git at git.irl.cs.ucla.edu:papers/nfd-docs.git (if you don?t have access, please contact Alexander Afanasyev <alexander.afanasyev at ucla.edu>). This document explains the internals of the NFD, and the target readers are people who may want to extend and improve NFD.  Each section corresponds to a module in NFD, and its content should include (1) the design and structure of the module, (2) the interaction between other modules, (3) explanation of major components of this module and their interactions, (4) figures to help understand the text. The hope is that after reading this guide, other developers would have good ideas of how NFD was designed and implemented, which will help them to plan any changes. 
> 
> Right now you?ll only find section titles in the repository. We will assign the writing of each section to the main developer who wrote the code, and you?ll soon receive Redmine emails about the assignment. The deadline is June 8, after which we?ll have one week to do integration. As always, please let us know ASAP if there?s any problem.
> 
> Thanks!
> 
> Beichuan
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev