From shijunxiao at email.arizona.edu  Fri Jan  1 03:03:15 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 1 Jan 2016 04:03:15 -0700
Subject: [Ndn-interest] NFD-Windows
In-Reply-To: <CAOFH+ObbFUN3G+MYmcJgyP=rHvbEF+Bv4h3_bQXxHdqg-t4b6w@mail.gmail.com>
References: <CAOFH+OaLL5NhJTANr3r1r=nGsEd3Lj=Gg9GbR+Bun+afHsCgQg@mail.gmail.com>
	<CAOFH+OacmYfzv=Q6XWkBk57H4vzG2S8nByAzcbUoMNLnRRiZVg@mail.gmail.com>
	<CAOFH+ObbFUN3G+MYmcJgyP=rHvbEF+Bv4h3_bQXxHdqg-t4b6w@mail.gmail.com>
Message-ID: <CAOFH+OadkHKFpyaw+nwdmG9_4H3YT1FwhYzometZoqUMbfafnQ@mail.gmail.com>

Dear folks

In this 2016's first post, I'd like to introduce NFD-Windows, Windows
builds of NDN software.
This project started during NDNcomm2015 hackathon, but I hit some roadblock
back then due to ongoing face refactoring. Now NFD 0.4.0 has been released
with face refactoring completed, and I'm able to successfully build and run
NFD on Windows.

NFD-Windows currently offers the following programs: ndnsec nfd nfdc
nfd-status ndnpeek ndnpoke ndnping ndnpingserver ndn-dissect infoedit.
Head over to https://yoursunny.com/p/NFD-Windows/ for download link and
more details.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160101/94ce4ab1/attachment.html>

From vslehman at memphis.edu  Tue Jan  5 14:33:46 2016
From: vslehman at memphis.edu (Vince Lehman (vslehman))
Date: Tue, 5 Jan 2016 22:33:46 +0000
Subject: [Ndn-interest] NLSR 0.2.2 release
Message-ID: <FDC7DE2A-90D2-4FB4-B99B-D11A5CF0FFD8@memphis.edu>

Dear all,

We are pleased to announce the release of version 0.2.2 of
Named-data Link State Routing Protocol (NLSR).

Version 0.2.2 makes NLSR compatible with the recent release
of version 0.4.0 of NFD and the ndn-cxx library.

Detailed release notes can be found at:
http://named-data.net/doc/NLSR/0.2.2/RELEASE-NOTES.html

More information about NLSR, tutorials, installation and configuration guides,
and other useful resources are available on the official webpage of NLSR:
http://named-data.net/doc/NLSR/0.2.2/

* * *
NLSR Developers and Contributors:
  Vince Lehman, A K M Mahmudul Hoque, Adam Alyyan, Syed Obaid Amin, Muktadir Chowdhury,
  Ashlesh Gawande, Minsheng Zhang, Lan Wang, Alexander Afanasyev, Spyridon Mastorakis,
  Jiewen Tan, Yingdi Yu, Lixia Zhang, Junxiao Shi, Beichuan Zhang

--
Vince Lehman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160105/30e4c8c1/attachment.html>

From daveoran at orandom.net  Sun Jan 10 08:09:02 2016
From: daveoran at orandom.net (David Oran)
Date: Sun, 10 Jan 2016 11:09:02 -0500
Subject: [Ndn-interest] Fwd: [icnrg] [riot-devel] RIOT Release 2015.12 (fwd)
References: <alpine.WNT.2.00.1601101649460.5620@mw-PC>
Message-ID: <2C2202F1-AB6D-470C-A76A-7976683D2FDC@orandom.net>



> Begin forwarded message:
> 
> From: Matthias Waehlisch <m.waehlisch at fu-berlin.de>
> Subject: [icnrg] [riot-devel] RIOT Release 2015.12 (fwd)
> Date: January 10, 2016 at 10:53:18 AM EST
> To: "icnrg at irtf.org" <icnrg at irtf.org>
> 
> Hi,
> 
>  the new RIOT release re-enables the support for ICN. More details 
> below.
> 
> 
> Cheers
>  matthias
> 
> 
> -- 
> Matthias Waehlisch
> .  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
> .  Takustr. 9, D-14195 Berlin, Germany
> .. mailto:waehlisch at ieee.org .. http://www.inf.fu-berlin.de/~waehl
> :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net
> 
> ---------- Forwarded message ----------
> Date: Sun, 10 Jan 2016 16:28:58 +0100
> From: Cenk G?ndogan <cenk.guendogan at fu-berlin.de>
> Reply-To: RIOT OS kernel developers <devel at riot-os.org>
> To: RIOT OS users list <users at riot-os.org>,
>    RIOT OS kernel developers <devel at riot-os.org>
> Subject: [riot-devel] RIOT Release 2015.12
> 
> Dear RIOT developers and users,
> 
> I am glad to announce the sixth official release of the RIOT operating 
> system:
> 
> ------------------------------- * RIOT 2015.12 * 
> -------------------------------
> 
> This release is packed with nearly 150 enhancements to the codebase and 
> bugfixes for several known issues. It also contains a lot of new 
> documentation as well as improvements to existing ones, which can be 
> found in http://doc.riot-os.org/.
> 
> In addition to the above, this new release re-enables the support for 
> ICN by integrating CCN-lite as a package and provides example 
> applications to showcase its functionality.
> 
> Developers can now make use of a Vagrant file that ships with this 
> release in order to manage a RIOT supported guest machine. This reduces 
> the set-up time by delivering a system with all necessary toolchains 
> installed without the need to touch the host system.
> 
> With a partial support of the Arduino API, RIOT becomes more accessible 
> to a wide range of Arduino specialized developers. Although this new 
> feature is still rudimentary, it already enables simple Arduino sketches 
> to be compiled into RIOT.
> 
> A further highlight of this release is the introduction of SAUL, the 
> [S]ensor [A]ctuator [U]ber [L]ayer. SAUL enables a portable approach to 
> interact with different types of sensors and actuators on RIOT supported 
> hardware by offering a unified API to the developer.
> 
> Several new platforms and device drivers found their way into this 
> release. RIOT 2015.12 supports the WeIO board, the Silicon Labs Wireless 
> Eval Kit (SLWSTK6220A) and the STM32 Nucleo-F401. With the new device 
> driver for the enc28j60 ethernet chip it is now possible to use wired 
> connections with RIOT.
> 
> Since the last release about 222 new pull requests with about 631 
> commits were merged and 48 additional issues have been solved. 37 people 
> generated a total of ~59779 insertions and ~12115 deletions in 980 
> files.
> 
> You can download the RIOT release from Github by cloning the 
> repositoryor by downloading the 
> tarball:https://github.com/RIOT-OS/RIOT/archive/2015.12.tar.gz
> 
> Keep RIOTing!
> 
> - Cenk
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel_______________________________________________
> icnrg mailing list
> icnrg at irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg




From Ignacio.Solis at parc.com  Thu Jan 14 03:06:59 2016
From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com)
Date: Thu, 14 Jan 2016 11:06:59 +0000
Subject: [Ndn-interest] CCNx source code release
Message-ID: <FB577887-A70A-4D39-BD7A-0E5E3A6EA63B@parc.com>

Hi folks.

We are pleased to announce that PARC is releasing the CCNx source code under a BSD-like license [1].  We will be uploading the code to github over the next couple of weeks.  As soon as it is up we?ll send an update with more information and instructions.

Discussion about the software will happen on the ccnx mailing list [2].

Cheers,

Nacho

[1] http://www.parc.com/news-release/111/parc-offers-content-centric-networking-ccnx-software-to-advance-next-generation-internet.html
[2] https://www.ccnx.org/<https://www.ccnx.org/mailman/listinfo/ccnx/>

--
Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
+1(650)812-4458
Ignacio.Solis at parc.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160114/3f3005ac/attachment.html>

From hughedwards94 at gmail.com  Thu Jan 14 14:19:57 2016
From: hughedwards94 at gmail.com (Hugh Edwards)
Date: Fri, 15 Jan 2016 08:49:57 +1030
Subject: [Ndn-interest] Understanding push-type data
Message-ID: <CAF0tj-bO_b7=q5R39zhs04sCSdr0zoUKPfG3FbEi4Uge1tt=Ow@mail.gmail.com>

Hi all,

I'm quite new to NDN, but I think beginning to get the hang of it.
One thing I'm getting stuck on understanding is how NDN supports pushed
data, or peer to peer communication. My understanding is that NDN
eventually aims to replace IP, rather than be used in conjunction with it
so this type of communication must be supported.

Basically I'm having trouble with the following:
For a client to send data to a server, it is possible to embed data in the
Interest (much like a HTTP GET request) which could be sent to a unique
prefix identifiable to a registered user on a website, for example. Is it
possible to guarantee the Interest will reach the server through having the
returned Data having a very brief freshness period?

That would work well for small amounts of data but for a file upload for
example, I imagine embedding that would be unwieldy and not conform to the
NDN convention.
However, to send a file otherwise would require (as far as I understand):
-The user sends an Interest to a reserved prefix which is guaranteed to
reach the server
-The server responds with an ACK (implementation specific, perhaps
unnecessary)
-The server sends an Interest to the user, as a go-ahead to send some data
-User responds to that Interest with the Data they initially wished to send

I don't understand in this instance how the server would be able to route
the data to the client, unless the client itself had a unique registered
prefix which it embedded within the initial Interest. And if that were the
case would that require every user to have a routable prefix which would
lead to their PC?

----

Secondly in regards to the synchronisation method of facilitating
pushed-type data:
in the ChronoSync paper (of ChronoChat) it seems that it requires a
specific prefix which utilises the broadcast strategy to effectively
communicate the state to all nodes. If multiple applications wished to use
their own broadcast prefix to use this type of synchronisation, would that
then require router configuration (presumably automatically) to have the
prefix registered and propagated such that other routers knew where to send
Data? And on an Internet scale, if a router didn't broadcast on this prefix
(it seems application specific, so only local routers would be configured
to broadcast for this) but instead used a best-route strategy, would that
then cause a network partition? How is it guaranteed that the
synchronisation method will reach all users requesting it?

I hope these questions make sense, and I realise they may be based on a
fundamental misunderstanding of the protocol.
Sorry for the wall of text :)

Thanks in advance,
Hugh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160115/4e2fb359/attachment.html>

From iliamo at CS.UCLA.EDU  Thu Jan 14 14:24:50 2016
From: iliamo at CS.UCLA.EDU (Ilya Moiseenko)
Date: Thu, 14 Jan 2016 17:24:50 -0500
Subject: [Ndn-interest] Understanding push-type data
In-Reply-To: <CAF0tj-bO_b7=q5R39zhs04sCSdr0zoUKPfG3FbEi4Uge1tt=Ow@mail.gmail.com>
References: <CAF0tj-bO_b7=q5R39zhs04sCSdr0zoUKPfG3FbEi4Uge1tt=Ow@mail.gmail.com>
Message-ID: <8DF73320-E05C-4586-8418-1F839598B611@cs.ucla.edu>

There is a paper about web interaction over NDN talking about the issues you mentioned
http://conferences2.sigcomm.org/acm-icn/2014/papers/p87.pdf <http://conferences2.sigcomm.org/acm-icn/2014/papers/p87.pdf>

Ilya

> On Jan 14, 2016, at 5:19 PM, Hugh Edwards <hughedwards94 at gmail.com> wrote:
> 
> Hi all,
> 
> I'm quite new to NDN, but I think beginning to get the hang of it.
> One thing I'm getting stuck on understanding is how NDN supports pushed data, or peer to peer communication. My understanding is that NDN eventually aims to replace IP, rather than be used in conjunction with it so this type of communication must be supported.
> 
> Basically I'm having trouble with the following:
> For a client to send data to a server, it is possible to embed data in the Interest (much like a HTTP GET request) which could be sent to a unique prefix identifiable to a registered user on a website, for example. Is it possible to guarantee the Interest will reach the server through having the returned Data having a very brief freshness period?
> 
> That would work well for small amounts of data but for a file upload for example, I imagine embedding that would be unwieldy and not conform to the NDN convention.
> However, to send a file otherwise would require (as far as I understand):
> -The user sends an Interest to a reserved prefix which is guaranteed to reach the server
> -The server responds with an ACK (implementation specific, perhaps unnecessary) 
> -The server sends an Interest to the user, as a go-ahead to send some data 
> -User responds to that Interest with the Data they initially wished to send
> 
> I don't understand in this instance how the server would be able to route the data to the client, unless the client itself had a unique registered prefix which it embedded within the initial Interest. And if that were the case would that require every user to have a routable prefix which would lead to their PC?
> 
> ----
> 
> Secondly in regards to the synchronisation method of facilitating pushed-type data:
> in the ChronoSync paper (of ChronoChat) it seems that it requires a specific prefix which utilises the broadcast strategy to effectively communicate the state to all nodes. If multiple applications wished to use their own broadcast prefix to use this type of synchronisation, would that then require router configuration (presumably automatically) to have the prefix registered and propagated such that other routers knew where to send Data? And on an Internet scale, if a router didn't broadcast on this prefix (it seems application specific, so only local routers would be configured to broadcast for this) but instead used a best-route strategy, would that then cause a network partition? How is it guaranteed that the synchronisation method will reach all users requesting it?
> 
> I hope these questions make sense, and I realise they may be based on a fundamental misunderstanding of the protocol. 
> Sorry for the wall of text :) 
> 
> Thanks in advance,
> Hugh. 
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160114/f533deb6/attachment.html>

From hughedwards94 at gmail.com  Thu Jan 14 17:26:15 2016
From: hughedwards94 at gmail.com (Hugh Edwards)
Date: Fri, 15 Jan 2016 11:56:15 +1030
Subject: [Ndn-interest] Understanding push-type data
In-Reply-To: <8DF73320-E05C-4586-8418-1F839598B611@cs.ucla.edu>
References: <CAF0tj-bO_b7=q5R39zhs04sCSdr0zoUKPfG3FbEi4Uge1tt=Ow@mail.gmail.com>
	<8DF73320-E05C-4586-8418-1F839598B611@cs.ucla.edu>
Message-ID: <CAF0tj-Yr63kdjC73kKdW2bq8Bw4QvT5xx6GX5YtsqjDdxbkh3Q@mail.gmail.com>

That was exactly what I was looking for, thank you.
I'm still curious about the scenario that I mentioned about ChronoSync /
broadcasting / partitioning.

I was also wondering if there were any apps available (perhaps even
compatible with the latest version of NFD) that utilise any of the
strategies mentioned in the article?
I bookmarked a modified ndn-cxx library 'consumer-producer api' that I
recall was developed for this purpose... Looking back at that page I notice
it's hosted on your GitHub page so I guess I'm asking the right person.

Thanks,
Hugh.

On Fri, Jan 15, 2016 at 8:54 AM, Ilya Moiseenko <iliamo at cs.ucla.edu> wrote:

> There is a paper about web interaction over NDN talking about the issues
> you mentioned
> http://conferences2.sigcomm.org/acm-icn/2014/papers/p87.pdf
>
> Ilya
>
> On Jan 14, 2016, at 5:19 PM, Hugh Edwards <hughedwards94 at gmail.com> wrote:
>
> Hi all,
>
> I'm quite new to NDN, but I think beginning to get the hang of it.
> One thing I'm getting stuck on understanding is how NDN supports pushed
> data, or peer to peer communication. My understanding is that NDN
> eventually aims to replace IP, rather than be used in conjunction with it
> so this type of communication must be supported.
>
> Basically I'm having trouble with the following:
> For a client to send data to a server, it is possible to embed data in the
> Interest (much like a HTTP GET request) which could be sent to a unique
> prefix identifiable to a registered user on a website, for example. Is it
> possible to guarantee the Interest will reach the server through having the
> returned Data having a very brief freshness period?
>
> That would work well for small amounts of data but for a file upload for
> example, I imagine embedding that would be unwieldy and not conform to the
> NDN convention.
> However, to send a file otherwise would require (as far as I understand):
> -The user sends an Interest to a reserved prefix which is guaranteed to
> reach the server
> -The server responds with an ACK (implementation specific, perhaps
> unnecessary)
> -The server sends an Interest to the user, as a go-ahead to send some data
> -User responds to that Interest with the Data they initially wished to send
>
> I don't understand in this instance how the server would be able to route
> the data to the client, unless the client itself had a unique registered
> prefix which it embedded within the initial Interest. And if that were the
> case would that require every user to have a routable prefix which would
> lead to their PC?
>
> ----
>
> Secondly in regards to the synchronisation method of facilitating
> pushed-type data:
> in the ChronoSync paper (of ChronoChat) it seems that it requires a
> specific prefix which utilises the broadcast strategy to effectively
> communicate the state to all nodes. If multiple applications wished to use
> their own broadcast prefix to use this type of synchronisation, would that
> then require router configuration (presumably automatically) to have the
> prefix registered and propagated such that other routers knew where to send
> Data? And on an Internet scale, if a router didn't broadcast on this prefix
> (it seems application specific, so only local routers would be configured
> to broadcast for this) but instead used a best-route strategy, would that
> then cause a network partition? How is it guaranteed that the
> synchronisation method will reach all users requesting it?
>
> I hope these questions make sense, and I realise they may be based on a
> fundamental misunderstanding of the protocol.
> Sorry for the wall of text :)
>
> Thanks in advance,
> Hugh.
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160115/38937d93/attachment.html>

From jp at wustl.edu  Fri Jan 15 08:20:51 2016
From: jp at wustl.edu (Jyoti Parwatikar)
Date: Fri, 15 Jan 2016 10:20:51 -0600
Subject: [Ndn-interest] using ValidatorConfig
Message-ID: <56991C63.7050404@wustl.edu>

I'm trying to create a validator using ValidatorConfig. In my 
configuration file, my checker is a fixed signer with type file.

The filename I give is of a file I created by creating a data key using 
ndnsec-key-gen followed by ndnsec-cert-gen and directing the output to a 
file.

When I try to load the file with a ValidatorConfig instance, I get the 
following error

  Cannot read certificate from file:

Does anyone have any ideas what I am doing wrong?

-Jyoti Parwatikar


From shijunxiao at email.arizona.edu  Fri Jan 15 10:17:02 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 15 Jan 2016 11:17:02 -0700
Subject: [Ndn-interest] using ValidatorConfig
In-Reply-To: <56991C63.7050404@wustl.edu>
References: <56991C63.7050404@wustl.edu>
Message-ID: <2795B60D-3C1D-4FDF-8A02-A2B078244AEE@email.arizona.edu>

Hi Jyoti

ValidatorConfig documentation <http://named-data.net/doc/ndn-cxx/current/tutorials/security-validator-config.html#fixed-signer-checker> is vague about whether a relative path in file-name field is resolved against the location of the configuration file or the current working directory.
Can you try specifying the full path in file-name field?

If it still doesn?t work, reply-all with the following:
the complete ValidatorConfig configuration
the code snippet that loads the configuration; in particular, is it loaded from a file or from a string
the full path of your certificate file
the first line of your certificate file (this helps determining whether you have the correct format in the certificate file)
what is the current working directory
what is the effective uid of the running program, and what Unix permissions does this uid have on the certificate file

Yours, Junxiao

> On Jan 15, 2016, at 9:20 AM, Jyoti Parwatikar <jp at wustl.edu> wrote:
> 
> I'm trying to create a validator using ValidatorConfig. In my configuration file, my checker is a fixed signer with type file.
> 
> The filename I give is of a file I created by creating a data key using ndnsec-key-gen followed by ndnsec-cert-gen and directing the output to a file.
> 
> When I try to load the file with a ValidatorConfig instance, I get the following error
> 
> Cannot read certificate from file:
> 
> Does anyone have any ideas what I am doing wrong?
> 
> -Jyoti Parwatikar
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160115/9dc14d2f/attachment.html>

From jp at wustl.edu  Fri Jan 15 10:21:08 2016
From: jp at wustl.edu (Jyoti Parwatikar)
Date: Fri, 15 Jan 2016 12:21:08 -0600
Subject: [Ndn-interest] using ValidatorConfig
In-Reply-To: <2795B60D-3C1D-4FDF-8A02-A2B078244AEE@email.arizona.edu>
References: <56991C63.7050404@wustl.edu>
	<2795B60D-3C1D-4FDF-8A02-A2B078244AEE@email.arizona.edu>
Message-ID: <56993894.8030406@wustl.edu>

Junxiao,

I am giving the full path.

-Jyoti

On 01/15/2016 12:17 PM, Junxiao Shi wrote:
> Hi Jyoti
>
> ValidatorConfig documentation 
> <http://named-data.net/doc/ndn-cxx/current/tutorials/security-validator-config.html#fixed-signer-checker> is 
> vague about whether a relative path in file-name field is resolved 
> against the location of the configuration file or the current working 
> directory.
> Can you try specifying the full path in file-name field?
>
> If it still doesn?t work, reply-all with the following:
>
>   * the complete ValidatorConfig configuration
>   * the code snippet that loads the configuration; in particular, is
>     it loaded from a file or from a string
>   * the full path of your certificate file
>   * the first line of your certificate file (this helps determining
>     whether you have the correct format in the certificate file)
>   * what is the current working directory
>   * what is the effective uid of the running program, and what Unix
>     permissions does this uid have on the certificate file
>
>
> Yours, Junxiao
>
>> On Jan 15, 2016, at 9:20 AM, Jyoti Parwatikar <jp at wustl.edu 
>> <mailto:jp at wustl.edu>> wrote:
>>
>> I'm trying to create a validator using ValidatorConfig. In my 
>> configuration file, my checker is a fixed signer with type file.
>>
>> The filename I give is of a file I created by creating a data key 
>> using ndnsec-key-gen followed by ndnsec-cert-gen and directing the 
>> output to a file.
>>
>> When I try to load the file with a ValidatorConfig instance, I get 
>> the following error
>>
>> Cannot read certificate from file:
>>
>> Does anyone have any ideas what I am doing wrong?
>>
>> -Jyoti Parwatikar
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu <mailto:Ndn-interest at lists.cs.ucla.edu>
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160115/e56af402/attachment.html>

From shijunxiao at email.arizona.edu  Fri Jan 15 10:20:30 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 15 Jan 2016 11:20:30 -0700
Subject: [Ndn-interest] using ValidatorConfig
In-Reply-To: <56993894.8030406@wustl.edu>
References: <56991C63.7050404@wustl.edu>
	<2795B60D-3C1D-4FDF-8A02-A2B078244AEE@email.arizona.edu>
	<56993894.8030406@wustl.edu>
Message-ID: <EA870886-01D7-4E4E-B355-796BD048F91B@email.arizona.edu>

Hi Jyoti

If giving the full path still doesn?t work, reply-all with the following:
the complete ValidatorConfig configuration
the code snippet that loads the configuration; in particular, is it loaded from a file or from a string
the full path of your certificate file
the first line of your certificate file (this helps determining whether you have the correct format in the certificate file)
what is the current working directory
what is the effective uid of the running program, and what Unix permissions does this uid have on the certificate file

Yours, Junxiao

> On Jan 15, 2016, at 11:21 AM, Jyoti Parwatikar <jp at wustl.edu> wrote:
> 
> Junxiao,
> 
> I am giving the full path.
> 
> -Jyoti
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160115/eec1d0c9/attachment.html>

From dennisolvany at gmail.com  Sun Jan 17 10:48:55 2016
From: dennisolvany at gmail.com (Dennis Olvany)
Date: Sun, 17 Jan 2016 18:48:55 +0000
Subject: [Ndn-interest] Usefulness of routing protocol?
Message-ID: <CAATNdDz44sG7c6h590xA=5xCmS+QCOhijQiHzm4scAdr06kGog@mail.gmail.com>

The flooding behavior of NDN is already akin to a routing protocol.
Clearly, there may be a benefit of knowing data reachability before
interest is expressed, but it is also not useful to know data reachability
if interest is never expressed. Is there a good use case for routing
protocol integration with NDN?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160117/83b55ec7/attachment.html>

From christos at colostate.edu  Sun Jan 17 11:26:40 2016
From: christos at colostate.edu (Christos Papadopoulos)
Date: Sun, 17 Jan 2016 12:26:40 -0700
Subject: [Ndn-interest] Usefulness of routing protocol?
In-Reply-To: <CAATNdDz44sG7c6h590xA=5xCmS+QCOhijQiHzm4scAdr06kGog@mail.gmail.com>
References: <CAATNdDz44sG7c6h590xA=5xCmS+QCOhijQiHzm4scAdr06kGog@mail.gmail.com>
Message-ID: <569BEAF0.3010306@colostate.edu>

Dennis,

Look at forwarding strategies in NDN.

Christos.


On 01/17/2016 11:48 AM, Dennis Olvany wrote:
> The flooding behavior of NDN is already akin to a routing protocol. 
> Clearly, there may be a benefit of knowing data reachability before 
> interest is expressed, but it is also not useful to know data 
> reachability if interest is never expressed. Is there a good use case 
> for routing protocol integration with NDN?
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160117/69b5685e/attachment.html>

From aa at CS.UCLA.EDU  Sun Jan 17 11:35:53 2016
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Sun, 17 Jan 2016 20:35:53 +0100
Subject: [Ndn-interest] Usefulness of routing protocol?
In-Reply-To: <CAATNdDz44sG7c6h590xA=5xCmS+QCOhijQiHzm4scAdr06kGog@mail.gmail.com>
References: <CAATNdDz44sG7c6h590xA=5xCmS+QCOhijQiHzm4scAdr06kGog@mail.gmail.com>
Message-ID: <68EE7AE7-3429-42C5-9E47-DED2D482635C@cs.ucla.edu>

Hi Dennis,

Flooding to do data discovery is not really an option in the Internet-scale environments.  To effectively work at such scale, we need a structured mechanism for data discovery, which is what dynamic routing protocols such as NLSR are trying to do.

In other environments, such ad hoc environments, I would 100% agree with you.  In such environments, an efficient way could be to just directly discover data (e.g., by some for of smart broadcasting) without need of any routing protocol (e.g., no need to set up routes separately before data communication, as done in aodv, dsr, and other ad hoc routing protocols today).

--
Alex

> On Jan 17, 2016, at 7:48 PM, Dennis Olvany <dennisolvany at gmail.com> wrote:
> 
> The flooding behavior of NDN is already akin to a routing protocol. Clearly, there may be a benefit of knowing data reachability before interest is expressed, but it is also not useful to know data reachability if interest is never expressed. Is there a good use case for routing protocol integration with NDN?
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160117/18d6e77d/attachment.bin>

From lixia at CS.UCLA.EDU  Sun Jan 17 11:50:26 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Sun, 17 Jan 2016 11:50:26 -0800
Subject: [Ndn-interest] Usefulness of routing protocol?
In-Reply-To: <CAATNdDz44sG7c6h590xA=5xCmS+QCOhijQiHzm4scAdr06kGog@mail.gmail.com>
References: <CAATNdDz44sG7c6h590xA=5xCmS+QCOhijQiHzm4scAdr06kGog@mail.gmail.com>
Message-ID: <A3216482-8D36-4E5D-9DE2-9803517B4031@cs.ucla.edu>


> On Jan 17, 2016, at 10:48 AM, Dennis Olvany <dennisolvany at gmail.com> wrote:
> 
> The flooding behavior of NDN is already akin to a routing protocol. Clearly, there may be a benefit of knowing data reachability before interest is expressed, but it is also not useful to know data reachability if interest is never expressed. Is there a good use case for routing protocol integration with NDN?

interesting questions.

let me ask a clarification question first: wonder exactly what you meant by "The flooding behavior of NDN"?

Since NDN interest looks for data and not aims at any specific node, NDN takes advantages of any communication media that is broadcast in nature (e.g. WiFi) in that whoever hears the questions may answer.  But I dont think NDN interests in general get flooded in wide areas.

Wonder exactly what you meant by "routing protocol integration with NDN"?  The NDN testbed is running a routing protocol.

Lixia


From s.h.ahmed at ieee.org  Sun Jan 17 18:23:50 2016
From: s.h.ahmed at ieee.org (Syed Hassan Ahmed)
Date: Mon, 18 Jan 2016 11:23:50 +0900
Subject: [Ndn-interest] Usefulness of routing protocol?
In-Reply-To: <A3216482-8D36-4E5D-9DE2-9803517B4031@cs.ucla.edu>
References: <CAATNdDz44sG7c6h590xA=5xCmS+QCOhijQiHzm4scAdr06kGog@mail.gmail.com>
	<A3216482-8D36-4E5D-9DE2-9803517B4031@cs.ucla.edu>
Message-ID: <CAJeX4qde4xOnf8vS9eJmFio0xAgU2u2cZTzhj=D5GkEmMn+BUA@mail.gmail.com>

Dear Dennis,
cc: Prof. Lixia Zhang and Dr. Alexander

Somehow your question is valid, since we use Broadcasting interface in case
of wireless, so eventually the Interest is flooded. For example, Every
neighboring node  of consumer C1, overhears the Interest packet, and then
has to perform all those basic operations, including PIT, CS, FIB search.
Moreover, if there is a case when those neighbors of C1 are not in intra
transmission range, may involve in interest forwarding as well. That
creates kind of broadcast storm, given that if there is only one provider
initially in the network. I have explored this problem in case of vehicular
environments, when we tried to simulate CCN on top of 802.11p. For
reference, please read my following paper:

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7145392

P.S: If you find my paper useful, don't hesitate to cite it :)

Kind Regards,
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
*Syed Hassan Ahmed*
??? ?? ????

PhD Research Scholar,
MoNeT Wireless Lab, <http://monet.knu.ac.kr>
Kyungpook National University,
Daegu City, Republic of Korea.
Cell: +82-10-9883-0786
https://sites.google.com/site/shahmedknu/

On Mon, Jan 18, 2016 at 4:50 AM, Lixia Zhang <lixia at cs.ucla.edu> wrote:

>
> > On Jan 17, 2016, at 10:48 AM, Dennis Olvany <dennisolvany at gmail.com>
> wrote:
> >
> > The flooding behavior of NDN is already akin to a routing protocol.
> Clearly, there may be a benefit of knowing data reachability before
> interest is expressed, but it is also not useful to know data reachability
> if interest is never expressed. Is there a good use case for routing
> protocol integration with NDN?
>
> interesting questions.
>
> let me ask a clarification question first: wonder exactly what you meant
> by "The flooding behavior of NDN"?
>
> Since NDN interest looks for data and not aims at any specific node, NDN
> takes advantages of any communication media that is broadcast in nature
> (e.g. WiFi) in that whoever hears the questions may answer.  But I dont
> think NDN interests in general get flooded in wide areas.
>
> Wonder exactly what you meant by "routing protocol integration with NDN"?
> The NDN testbed is running a routing protocol.
>
> Lixia
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160118/8959195a/attachment.html>

From dennisolvany at gmail.com  Sun Jan 17 19:22:49 2016
From: dennisolvany at gmail.com (Dennis Olvany)
Date: Mon, 18 Jan 2016 03:22:49 +0000
Subject: [Ndn-interest] Usefulness of routing protocol?
In-Reply-To: <CAJeX4qde4xOnf8vS9eJmFio0xAgU2u2cZTzhj=D5GkEmMn+BUA@mail.gmail.com>
References: <CAATNdDz44sG7c6h590xA=5xCmS+QCOhijQiHzm4scAdr06kGog@mail.gmail.com>
	<A3216482-8D36-4E5D-9DE2-9803517B4031@cs.ucla.edu>
	<CAJeX4qde4xOnf8vS9eJmFio0xAgU2u2cZTzhj=D5GkEmMn+BUA@mail.gmail.com>
Message-ID: <CAATNdDxNfuMQbDAbTeysVtmN20qbfDCLNGFK4G5NtHVHoBqTig@mail.gmail.com>

Lixia,

The NDN papers that I have read thus far seem to suggest that a router
receives an interest on a given face and then forwards the interest out of
its other faces. My impression is that this occurs at each router in the
network until the interest reaches the origin. As the data returns to the
client, all routers will learn the path based on the data incoming face.
Routers could then cease flooding once there is a known path. Clearly, my
understanding may be incorrect as I have only been researching NDN for a
week.

-Dennis
On Sun, Jan 17, 2016 at 9:23 PM Syed Hassan Ahmed <s.h.ahmed at ieee.org>
wrote:

> Dear Dennis,
> cc: Prof. Lixia Zhang and Dr. Alexander
>
> Somehow your question is valid, since we use Broadcasting interface in
> case of wireless, so eventually the Interest is flooded. For example, Every
> neighboring node  of consumer C1, overhears the Interest packet, and then
> has to perform all those basic operations, including PIT, CS, FIB search.
> Moreover, if there is a case when those neighbors of C1 are not in intra
> transmission range, may involve in interest forwarding as well. That
> creates kind of broadcast storm, given that if there is only one provider
> initially in the network. I have explored this problem in case of vehicular
> environments, when we tried to simulate CCN on top of 802.11p. For
> reference, please read my following paper:
>
> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7145392
>
> P.S: If you find my paper useful, don't hesitate to cite it :)
>
> Kind Regards,
> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
> *Syed Hassan Ahmed*
> ??? ?? ????
>
> PhD Research Scholar,
> MoNeT Wireless Lab, <http://monet.knu.ac.kr>
> Kyungpook National University,
> Daegu City, Republic of Korea.
> Cell: +82-10-9883-0786
> https://sites.google.com/site/shahmedknu/
>
> On Mon, Jan 18, 2016 at 4:50 AM, Lixia Zhang <lixia at cs.ucla.edu> wrote:
>
>>
>> > On Jan 17, 2016, at 10:48 AM, Dennis Olvany <dennisolvany at gmail.com>
>> wrote:
>> >
>> > The flooding behavior of NDN is already akin to a routing protocol.
>> Clearly, there may be a benefit of knowing data reachability before
>> interest is expressed, but it is also not useful to know data reachability
>> if interest is never expressed. Is there a good use case for routing
>> protocol integration with NDN?
>>
>> interesting questions.
>>
>> let me ask a clarification question first: wonder exactly what you meant
>> by "The flooding behavior of NDN"?
>>
>> Since NDN interest looks for data and not aims at any specific node, NDN
>> takes advantages of any communication media that is broadcast in nature
>> (e.g. WiFi) in that whoever hears the questions may answer.  But I dont
>> think NDN interests in general get flooded in wide areas.
>>
>> Wonder exactly what you meant by "routing protocol integration with
>> NDN"?  The NDN testbed is running a routing protocol.
>>
>> Lixia
>>
> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160118/3a8635af/attachment.html>

From dennisolvany at gmail.com  Sun Jan 17 20:03:07 2016
From: dennisolvany at gmail.com (Dennis Olvany)
Date: Mon, 18 Jan 2016 04:03:07 +0000
Subject: [Ndn-interest] Usefulness of routing protocol?
In-Reply-To: <4AC03A6244C3C34BB52A7EC60B799C4C03CC29EA@m-pdc.sbu.ac.ir>
References: <CAATNdDz44sG7c6h590xA=5xCmS+QCOhijQiHzm4scAdr06kGog@mail.gmail.com>
	<A3216482-8D36-4E5D-9DE2-9803517B4031@cs.ucla.edu>
	<CAJeX4qde4xOnf8vS9eJmFio0xAgU2u2cZTzhj=D5GkEmMn+BUA@mail.gmail.com>
	<CAATNdDxNfuMQbDAbTeysVtmN20qbfDCLNGFK4G5NtHVHoBqTig@mail.gmail.com>
	<4AC03A6244C3C34BB52A7EC60B799C4C03CC29EA@m-pdc.sbu.ac.ir>
Message-ID: <CAATNdDxH0-nN_=gfRcts9TjX=8LysLcaHyAuYCN5i3QB77NedQ@mail.gmail.com>

Paper located--will give it a read. Thx!
On Sun, Jan 17, 2016 at 10:45 PM Muhammad Hosain Abdollahi Sabet <
M.AbdollahiSabet at mail.sbu.ac.ir> wrote:

> Hi Dennis,
>
> If that is the case, you can take a look at forwarding strategies(Adaptive
> Forwarding paper which you can find it on named-data.net) and also Link
> State Routing Protocol(NLSR).
>
>
> What you're saying is not exactly the way ndn network works. Initial
> flooding could be a solution in LANs, maybe. But in large scales, no.
>
> Thanks,
> Sabet
>
>
> -----Original Message-----
> From: Ndn-interest on behalf of Dennis Olvany
> Sent: Mon 1/18/2016 6:52 AM
> To: Syed Hassan Ahmed; Lixia Zhang
> Cc: ndn-interest at lists.cs.ucla.edu
> Subject: Re: [Ndn-interest] Usefulness of routing protocol?
>
> Lixia,
>
> The NDN papers that I have read thus far seem to suggest that a router
> receives an interest on a given face and then forwards the interest out of
> its other faces. My impression is that this occurs at each router in the
> network until the interest reaches the origin. As the data returns to the
> client, all routers will learn the path based on the data incoming face.
> Routers could then cease flooding once there is a known path. Clearly, my
> understanding may be incorrect as I have only been researching NDN for a
> week.
>
> -Dennis
> On Sun, Jan 17, 2016 at 9:23 PM Syed Hassan Ahmed <s.h.ahmed at ieee.org>
> wrote:
>
> > Dear Dennis,
> > cc: Prof. Lixia Zhang and Dr. Alexander
> >
> > Somehow your question is valid, since we use Broadcasting interface in
> > case of wireless, so eventually the Interest is flooded. For example,
> Every
> > neighboring node  of consumer C1, overhears the Interest packet, and then
> > has to perform all those basic operations, including PIT, CS, FIB search.
> > Moreover, if there is a case when those neighbors of C1 are not in intra
> > transmission range, may involve in interest forwarding as well. That
> > creates kind of broadcast storm, given that if there is only one provider
> > initially in the network. I have explored this problem in case of
> vehicular
> > environments, when we tried to simulate CCN on top of 802.11p. For
> > reference, please read my following paper:
> >
> > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7145392
> >
> > P.S: If you find my paper useful, don't hesitate to cite it :)
> >
> > Kind Regards,
> > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
>
> > *Syed Hassan Ahmed*
> > ??? ?? ????
> >
>
> > PhD Research Scholar,
> > MoNeT Wireless Lab, <http://monet.knu.ac.kr>
>
>
> > Kyungpook National University,
> > Daegu City, Republic of Korea.
> > Cell: +82-10-9883-0786
> > https://sites.google.com/site/shahmedknu/
> >
> > On Mon, Jan 18, 2016 at 4:50 AM, Lixia Zhang <lixia at cs.ucla.edu> wrote:
> >
> >>
> >> > On Jan 17, 2016, at 10:48 AM, Dennis Olvany <dennisolvany at gmail.com>
> >> wrote:
> >> >
> >> > The flooding behavior of NDN is already akin to a routing protocol.
> >> Clearly, there may be a benefit of knowing data reachability before
> >> interest is expressed, but it is also not useful to know data
> reachability
> >> if interest is never expressed. Is there a good use case for routing
> >> protocol integration with NDN?
> >>
> >> interesting questions.
> >>
> >> let me ask a clarification question first: wonder exactly what you meant
> >> by "The flooding behavior of NDN"?
> >>
> >> Since NDN interest looks for data and not aims at any specific node, NDN
> >> takes advantages of any communication media that is broadcast in nature
> >> (e.g. WiFi) in that whoever hears the questions may answer.  But I dont
> >> think NDN interests in general get flooded in wide areas.
> >>
> >> Wonder exactly what you meant by "routing protocol integration with
> >> NDN"?  The NDN testbed is running a routing protocol.
> >>
> >> Lixia
> >>
> > _______________________________________________
> >> Ndn-interest mailing list
> >> Ndn-interest at lists.cs.ucla.edu
> >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160118/b683f32a/attachment.html>

From lixia at CS.UCLA.EDU  Sun Jan 17 20:10:37 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Sun, 17 Jan 2016 20:10:37 -0800
Subject: [Ndn-interest] Usefulness of routing protocol?
In-Reply-To: <CAATNdDxNfuMQbDAbTeysVtmN20qbfDCLNGFK4G5NtHVHoBqTig@mail.gmail.com>
References: <CAATNdDz44sG7c6h590xA=5xCmS+QCOhijQiHzm4scAdr06kGog@mail.gmail.com>
	<A3216482-8D36-4E5D-9DE2-9803517B4031@cs.ucla.edu>
	<CAJeX4qde4xOnf8vS9eJmFio0xAgU2u2cZTzhj=D5GkEmMn+BUA@mail.gmail.com>
	<CAATNdDxNfuMQbDAbTeysVtmN20qbfDCLNGFK4G5NtHVHoBqTig@mail.gmail.com>
Message-ID: <F9823D39-66CF-4EC8-A5D6-50CE3D214EA0@cs.ucla.edu>


> On Jan 17, 2016, at 7:22 PM, Dennis Olvany <dennisolvany at gmail.com> wrote:
> 
> Lixia,
> 
> The NDN papers that I have read thus far seem to suggest that a router receives an interest on a given face and then forwards the interest out of its other faces.

could you please point me to those papers?
I am aware of the first paper (published in CoNext 2009) that mentioned about 
"A consumer asks for content by broadcasting its interest over all avail- able connectivity. Any node hearing the interest and having data that satisfies it can respond with a Data packet." 

1) this is talking about a consumer; 2) a consumer runs a forwarding strategy module that decides what's the best thing to do for each interest (may/may not broadcast)


> My impression is that this occurs at each router in the network until the interest reaches the origin.

that does not match my understanding.

> As the data returns to the client, all routers will learn the path based on the data incoming face. Routers could then cease flooding once there is a known path. Clearly, my understanding may be incorrect as I have only been researching NDN for a week.

Do appreciate that you brought up the question so we can clarify this.
Wonder whether you watched some of the NDN tutorials? e.g. the one at ICN 2014 (you can find it from http://named-data.net/publications/tutorials/ <http://named-data.net/publications/tutorials/>)

Lixia


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160117/fa2cda9c/attachment.html>

From lixia at CS.UCLA.EDU  Sun Jan 17 22:05:58 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Sun, 17 Jan 2016 22:05:58 -0800
Subject: [Ndn-interest] Usefulness of routing protocol?
In-Reply-To: <CAJeX4qde4xOnf8vS9eJmFio0xAgU2u2cZTzhj=D5GkEmMn+BUA@mail.gmail.com>
References: <CAATNdDz44sG7c6h590xA=5xCmS+QCOhijQiHzm4scAdr06kGog@mail.gmail.com>
	<A3216482-8D36-4E5D-9DE2-9803517B4031@cs.ucla.edu>
	<CAJeX4qde4xOnf8vS9eJmFio0xAgU2u2cZTzhj=D5GkEmMn+BUA@mail.gmail.com>
Message-ID: <36B3DE45-ED4C-4031-9CA9-1220E3FB81EB@cs.ucla.edu>


> On Jan 17, 2016, at 6:23 PM, Syed Hassan Ahmed <s.h.ahmed at ieee.org> wrote:
> 
> Dear Dennis,
> cc: Prof. Lixia Zhang and Dr. Alexander 
> 
> Somehow your question is valid, since we use Broadcasting interface in case of wireless, so eventually the Interest is flooded. For example, Every neighboring node  of consumer C1, overhears the Interest packet, and then has to perform all those basic operations, including PIT, CS, FIB search. Moreover, if there is a case when those neighbors of C1 are not in intra transmission range, may involve in interest forwarding as well. That creates kind of broadcast storm, given that if there is only one provider initially in the network. I have explored this problem in case of vehicular environments, when we tried to simulate CCN on top of 802.11p. For reference, please read my following paper: 
> 
> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7145392 <http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7145392>
Dear Syed Hassan,

thanks for your explanation of what happened in your scenario. I am afraid that specific scenario suffered a design defect.
In a all-wireless network (instead of a local wireless hop), one must have an effective way for individual nodes to decide whether it should, or should not, forward each received interest; e.g. see a simple example in this short paper (also on vehicular networking): "Rapid Traffic Information Dissemination Using Named Data" http://named-data.net/publications/nom/ <http://named-data.net/publications/nom/>

If you are interested in this topic (about how to control packet flooding in all-wireless broadcast environment): some sensor networking research work about a decade ago produced a rich set of literatures on this topic,
"Directed Diffusion for Wireless Sensor Networking" (just google it, it has about 3000 citations)
another one: "GRAdient Broadcast: A robust Data Delivery Protocol for Large Scale Sensor Networks" 

Lixia


> PhD Research Scholar,
> MoNeT Wireless Lab, <http://monet.knu.ac.kr/>
> Kyungpook National University,
> Daegu City, Republic of Korea.
> Cell: +82-10-9883-0786
> https://sites.google.com/site/shahmedknu/ <https://sites.google.com/site/shahmedknu/> 
> 
> On Mon, Jan 18, 2016 at 4:50 AM, Lixia Zhang <lixia at cs.ucla.edu <mailto:lixia at cs.ucla.edu>> wrote:
> 
> > On Jan 17, 2016, at 10:48 AM, Dennis Olvany <dennisolvany at gmail.com <mailto:dennisolvany at gmail.com>> wrote:
> >
> > The flooding behavior of NDN is already akin to a routing protocol. Clearly, there may be a benefit of knowing data reachability before interest is expressed, but it is also not useful to know data reachability if interest is never expressed. Is there a good use case for routing protocol integration with NDN?
> 
> interesting questions.
> 
> let me ask a clarification question first: wonder exactly what you meant by "The flooding behavior of NDN"?
> 
> Since NDN interest looks for data and not aims at any specific node, NDN takes advantages of any communication media that is broadcast in nature (e.g. WiFi) in that whoever hears the questions may answer.  But I dont think NDN interests in general get flooded in wide areas.
> 
> Wonder exactly what you meant by "routing protocol integration with NDN"?  The NDN testbed is running a routing protocol.
> 
> Lixia
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu <mailto:Ndn-interest at lists.cs.ucla.edu>
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest <http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160117/359f7c9f/attachment.html>

From s.h.ahmed at ieee.org  Sun Jan 17 22:41:44 2016
From: s.h.ahmed at ieee.org (Syed Hassan Ahmed)
Date: Mon, 18 Jan 2016 15:41:44 +0900
Subject: [Ndn-interest] Usefulness of routing protocol?
In-Reply-To: <36B3DE45-ED4C-4031-9CA9-1220E3FB81EB@cs.ucla.edu>
References: <CAATNdDz44sG7c6h590xA=5xCmS+QCOhijQiHzm4scAdr06kGog@mail.gmail.com>
	<A3216482-8D36-4E5D-9DE2-9803517B4031@cs.ucla.edu>
	<CAJeX4qde4xOnf8vS9eJmFio0xAgU2u2cZTzhj=D5GkEmMn+BUA@mail.gmail.com>
	<36B3DE45-ED4C-4031-9CA9-1220E3FB81EB@cs.ucla.edu>
Message-ID: <CAJeX4qcCTsDZCgvctkDniMU1LE3DOqDvEhXTCEYQ3SEXvRuaMw@mail.gmail.com>

Dear Prof. Lixia Zhang,

I understand your point. In fact, I have read those papers that you
mentioned. However, I believe that existing solutions will require
significant changes before they can work well for NDN. Since these
solutions were designed for a specific networking protocol such as
Zigbee, 802.15.4, 802.11 family and so on. Here when we talk about NDN, we
are moving towards multiple interfaces (faces) as per my understanding.
Moreover, I would like to take your attention to the recent paper published
in the ACM Sigcom Workshop 2013,

http://conferences.sigcomm.org/sigcomm/2013/papers/mcc/p21.pdf

In this paper, the authors intended to mitigate the broadcast storm, since
the battery operated devices might be consuming additional energy to
perform all those searches and forwarding operations enforced by the Naive
NDN approach.

Also, the following survey provides some insights on the forwarding of
interest in NDN enabled wireless ad hoc scenarios.
http://www.sciencedirect.com/science/article/pii/S1084804514001404

To be precise, in mobile environments, I think it is worthy to investigate
the forwarding strategies, and still we need improvements at the
architectural level that should accept the modifications and new forwarding
protocols specific to the application requirements and so. For example, by
exchanging some control messages such as Beacons in case of 802.11p, we can
have some preliminary knowledge about the neighboring nodes and then the
consumer can decide and control the Interest propagation and similarly the
intermediate nodes as well.



Kind Regards,
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
*Syed Hassan Ahmed*
??? ?? ????

PhD Research Scholar,
MoNeT Wireless Lab, <http://monet.knu.ac.kr>
Kyungpook National University,
Daegu City, Republic of Korea.
Cell: +82-10-9883-0786
https://sites.google.com/site/shahmedknu/

On Mon, Jan 18, 2016 at 3:05 PM, Lixia Zhang <lixia at cs.ucla.edu> wrote:

>
> On Jan 17, 2016, at 6:23 PM, Syed Hassan Ahmed <s.h.ahmed at ieee.org> wrote:
>
> Dear Dennis,
> cc: Prof. Lixia Zhang and Dr. Alexander
>
> Somehow your question is valid, since we use Broadcasting interface in
> case of wireless, so eventually the Interest is flooded. For example, Every
> neighboring node  of consumer C1, overhears the Interest packet, and then
> has to perform all those basic operations, including PIT, CS, FIB search.
> Moreover, if there is a case when those neighbors of C1 are not in intra
> transmission range, may involve in interest forwarding as well. That
> creates kind of broadcast storm, given that if there is only one provider
> initially in the network. I have explored this problem in case of vehicular
> environments, when we tried to simulate CCN on top of 802.11p. For
> reference, please read my following paper:
>
> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7145392
>
>
> Dear Syed Hassan,
>
> thanks for your explanation of what happened in your scenario. I am afraid
> that specific scenario suffered a design defect.
> In a all-wireless network (instead of a local wireless hop), one must have
> an effective way for individual nodes to decide whether it should, or
> should not, forward each received interest; e.g. see a simple example in
> this short paper (also on vehicular networking): "Rapid Traffic Information
> Dissemination Using Named Data" http://named-data.net/publications/nom/
>
> If you are interested in this topic (about how to control packet flooding
> in all-wireless broadcast environment): some sensor networking research
> work about a decade ago produced a rich set of literatures on this topic,
> "Directed Diffusion for Wireless Sensor Networking" (just google it, it
> has about 3000 citations)
> another one: "GRAdient Broadcast: A robust Data Delivery Protocol for
> Large Scale Sensor Networks"
>
> Lixia
>
>
> PhD Research Scholar,
> MoNeT Wireless Lab, <http://monet.knu.ac.kr/>
> Kyungpook National University,
> Daegu City, Republic of Korea.
> Cell: +82-10-9883-0786
> https://sites.google.com/site/shahmedknu/
>
> On Mon, Jan 18, 2016 at 4:50 AM, Lixia Zhang <lixia at cs.ucla.edu> wrote:
>
>>
>> > On Jan 17, 2016, at 10:48 AM, Dennis Olvany <dennisolvany at gmail.com>
>> wrote:
>> >
>> > The flooding behavior of NDN is already akin to a routing protocol.
>> Clearly, there may be a benefit of knowing data reachability before
>> interest is expressed, but it is also not useful to know data reachability
>> if interest is never expressed. Is there a good use case for routing
>> protocol integration with NDN?
>>
>> interesting questions.
>>
>> let me ask a clarification question first: wonder exactly what you meant
>> by "The flooding behavior of NDN"?
>>
>> Since NDN interest looks for data and not aims at any specific node, NDN
>> takes advantages of any communication media that is broadcast in nature
>> (e.g. WiFi) in that whoever hears the questions may answer.  But I dont
>> think NDN interests in general get flooded in wide areas.
>>
>> Wonder exactly what you meant by "routing protocol integration with
>> NDN"?  The NDN testbed is running a routing protocol.
>>
>> Lixia
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160118/8da6b99f/attachment.html>

From lixia at CS.UCLA.EDU  Sun Jan 17 23:05:27 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Sun, 17 Jan 2016 23:05:27 -0800
Subject: [Ndn-interest] Usefulness of routing protocol?
In-Reply-To: <CAJeX4qcCTsDZCgvctkDniMU1LE3DOqDvEhXTCEYQ3SEXvRuaMw@mail.gmail.com>
References: <CAATNdDz44sG7c6h590xA=5xCmS+QCOhijQiHzm4scAdr06kGog@mail.gmail.com>
	<A3216482-8D36-4E5D-9DE2-9803517B4031@cs.ucla.edu>
	<CAJeX4qde4xOnf8vS9eJmFio0xAgU2u2cZTzhj=D5GkEmMn+BUA@mail.gmail.com>
	<36B3DE45-ED4C-4031-9CA9-1220E3FB81EB@cs.ucla.edu>
	<CAJeX4qcCTsDZCgvctkDniMU1LE3DOqDvEhXTCEYQ3SEXvRuaMw@mail.gmail.com>
Message-ID: <4F4A9CD7-E2C7-483D-B6CD-61B523053E85@cs.ucla.edu>

Thanks for the additional pointers to the literature.
Your msg suggests that we agree on the need for smart forwarding decisions to avoid flooding storms; naive flooding does not work.

NDN is a research project and welcomes new contributions.
I agree too that forwarding strategy is a great area for new research efforts.

Lixia

> On Jan 17, 2016, at 10:41 PM, Syed Hassan Ahmed <s.h.ahmed at ieee.org> wrote:
> 
> Dear Prof. Lixia Zhang, 
> 
> I understand your point. In fact, I have read those papers that you mentioned. However, I believe that existing solutions will require significant changes before they can work well for NDN. Since these solutions were designed for a specific networking protocol such as Zigbee, 802.15.4, 802.11 family and so on. Here when we talk about NDN, we are moving towards multiple interfaces (faces) as per my understanding. Moreover, I would like to take your attention to the recent paper published in the ACM Sigcom Workshop 2013,
> 
> http://conferences.sigcomm.org/sigcomm/2013/papers/mcc/p21.pdf <http://conferences.sigcomm.org/sigcomm/2013/papers/mcc/p21.pdf>
> 
> In this paper, the authors intended to mitigate the broadcast storm, since the battery operated devices might be consuming additional energy to perform all those searches and forwarding operations enforced by the Naive NDN approach.
> 
> Also, the following survey provides some insights on the forwarding of interest in NDN enabled wireless ad hoc scenarios. 
> http://www.sciencedirect.com/science/article/pii/S1084804514001404 <http://www.sciencedirect.com/science/article/pii/S1084804514001404>
> 
> To be precise, in mobile environments, I think it is worthy to investigate the forwarding strategies, and still we need improvements at the architectural level that should accept the modifications and new forwarding protocols specific to the application requirements and so. For example, by exchanging some control messages such as Beacons in case of 802.11p, we can have some preliminary knowledge about the neighboring nodes and then the consumer can decide and control the Interest propagation and similarly the intermediate nodes as well. 
> 
> Kind Regards,
> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
> Syed Hassan Ahmed
> ??? ?? ????
> 
> PhD Research Scholar,
> MoNeT Wireless Lab, <http://monet.knu.ac.kr/>
> Kyungpook National University,
> Daegu City, Republic of Korea.
> Cell: +82-10-9883-0786
> https://sites.google.com/site/shahmedknu/ <https://sites.google.com/site/shahmedknu/> 
> 
> On Mon, Jan 18, 2016 at 3:05 PM, Lixia Zhang <lixia at cs.ucla.edu <mailto:lixia at cs.ucla.edu>> wrote:
> 
>> On Jan 17, 2016, at 6:23 PM, Syed Hassan Ahmed <s.h.ahmed at ieee.org <mailto:s.h.ahmed at ieee.org>> wrote:
>> 
>> Dear Dennis,
>> cc: Prof. Lixia Zhang and Dr. Alexander 
>> 
>> Somehow your question is valid, since we use Broadcasting interface in case of wireless, so eventually the Interest is flooded. For example, Every neighboring node  of consumer C1, overhears the Interest packet, and then has to perform all those basic operations, including PIT, CS, FIB search. Moreover, if there is a case when those neighbors of C1 are not in intra transmission range, may involve in interest forwarding as well. That creates kind of broadcast storm, given that if there is only one provider initially in the network. I have explored this problem in case of vehicular environments, when we tried to simulate CCN on top of 802.11p. For reference, please read my following paper: 
>> 
>> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7145392 <http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7145392>
> Dear Syed Hassan,
> 
> thanks for your explanation of what happened in your scenario. I am afraid that specific scenario suffered a design defect.
> In a all-wireless network (instead of a local wireless hop), one must have an effective way for individual nodes to decide whether it should, or should not, forward each received interest; e.g. see a simple example in this short paper (also on vehicular networking): "Rapid Traffic Information Dissemination Using Named Data" http://named-data.net/publications/nom/ <http://named-data.net/publications/nom/>
> 
> If you are interested in this topic (about how to control packet flooding in all-wireless broadcast environment): some sensor networking research work about a decade ago produced a rich set of literatures on this topic,
> "Directed Diffusion for Wireless Sensor Networking" (just google it, it has about 3000 citations)
> another one: "GRAdient Broadcast: A robust Data Delivery Protocol for Large Scale Sensor Networks" 
> 
> Lixia
> 
> 
>> PhD Research Scholar,
>> MoNeT Wireless Lab, <http://monet.knu.ac.kr/>
>> Kyungpook National University,
>> Daegu City, Republic of Korea.
>> Cell: +82-10-9883-0786
>> https://sites.google.com/site/shahmedknu/ <https://sites.google.com/site/shahmedknu/> 
>> 
>> On Mon, Jan 18, 2016 at 4:50 AM, Lixia Zhang <lixia at cs.ucla.edu <mailto:lixia at cs.ucla.edu>> wrote:
>> 
>> > On Jan 17, 2016, at 10:48 AM, Dennis Olvany <dennisolvany at gmail.com <mailto:dennisolvany at gmail.com>> wrote:
>> >
>> > The flooding behavior of NDN is already akin to a routing protocol. Clearly, there may be a benefit of knowing data reachability before interest is expressed, but it is also not useful to know data reachability if interest is never expressed. Is there a good use case for routing protocol integration with NDN?
>> 
>> interesting questions.
>> 
>> let me ask a clarification question first: wonder exactly what you meant by "The flooding behavior of NDN"?
>> 
>> Since NDN interest looks for data and not aims at any specific node, NDN takes advantages of any communication media that is broadcast in nature (e.g. WiFi) in that whoever hears the questions may answer.  But I dont think NDN interests in general get flooded in wide areas.
>> 
>> Wonder exactly what you meant by "routing protocol integration with NDN"?  The NDN testbed is running a routing protocol.
>> 
>> Lixia
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu <mailto:Ndn-interest at lists.cs.ucla.edu>
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest <http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest>
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160117/67ed7883/attachment.html>

From NourElHouda.BenYoussef at oxia-group.com  Tue Jan 19 02:15:48 2016
From: NourElHouda.BenYoussef at oxia-group.com (Nour El Houda Ben Youssef)
Date: Tue, 19 Jan 2016 10:15:48 +0000
Subject: [Ndn-interest] Unreachable nodes while calculating routes
Message-ID: <712FE4E7257849499414892DD92704BC73256759@INFRAEX02.oxia.corp>

Dear all

I built a simple topology using ns-3 PLC module on top of which ndnSim is deployed

When I try to calculate Routes I get the following error:

0s -1 ndn.GlobalRoutingHelper:CalculateRoutes(): [DEBUG] Reachability from Node: 0
is unreachable
0s -1 ndn.GlobalRoutingHelper:CalculateRoutes(): [DEBUG] Reachability from Node: 1
is unreachable

Can you please explain the reason behind this error
Best regards


Nour El Houda Ben Youssef Koubaa
PhD student Mobidoc - OXIA/SAGE
Master degree: new genereation of information systems - FST
Software engineer - INSAT
TUNISIA


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160119/b65e4ea9/attachment.html>

From harsh0233 at gmail.com  Tue Jan 19 22:55:16 2016
From: harsh0233 at gmail.com (harshit singh)
Date: Wed, 20 Jan 2016 12:25:16 +0530
Subject: [Ndn-interest] ndn
Message-ID: <CAOxrW9uDAMzR3NrtyTnYKkO6KOciwf62qoUZj0UfnLMsMT+=NA@mail.gmail.com>

Hello

I have already installed nfd on both android devices but I dont know how to
register with ndn daemon (as shown by you in demo of ndnwhiteboard).Please
provide some valuable suggestion for the same.What I mean is that what
should be there in faceuri and prefix(for creating route).


regards
Harshit Singh
B.Tech CSE
IIT Roorkee
Roorkee-247667
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160120/f876d750/attachment.html>

From josh at caida.org  Wed Jan 20 09:37:46 2016
From: josh at caida.org (Josh Polterock)
Date: Wed, 20 Jan 2016 09:37:46 -0800
Subject: [Ndn-interest] ndn
In-Reply-To: <CAOxrW9uDAMzR3NrtyTnYKkO6KOciwf62qoUZj0UfnLMsMT+=NA@mail.gmail.com>
References: <CAOxrW9uDAMzR3NrtyTnYKkO6KOciwf62qoUZj0UfnLMsMT+=NA@mail.gmail.com>
Message-ID: <20160120173746.GP89996@caida.org>

Harshit Singh,

I have not played around with Android yet but I expect this post on
getting NFD connect should still apply.

http://named-data.net/2015/01/06/get-nfd-connected/

I hope this helps.

Regards,
Josh

On Wed, Jan 20, 2016 at 12:25:16PM +0530, harshit singh wrote:
> Hello
> 
> I have already installed nfd on both android devices but I dont know how to
> register with ndn daemon (as shown by you in demo of ndnwhiteboard).Please
> provide some valuable suggestion for the same.What I mean is that what
> should be there in faceuri and prefix(for creating route).
> 
> 
> regards
> Harshit Singh
> B.Tech CSE
> IIT Roorkee
> Roorkee-247667

> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest



From iliamo at CS.UCLA.EDU  Thu Jan 21 08:21:17 2016
From: iliamo at CS.UCLA.EDU (Ilya Moiseenko)
Date: Thu, 21 Jan 2016 11:21:17 -0500
Subject: [Ndn-interest] Understanding push-type data
In-Reply-To: <CAF0tj-Yr63kdjC73kKdW2bq8Bw4QvT5xx6GX5YtsqjDdxbkh3Q@mail.gmail.com>
References: <CAF0tj-bO_b7=q5R39zhs04sCSdr0zoUKPfG3FbEi4Uge1tt=Ow@mail.gmail.com>
	<8DF73320-E05C-4586-8418-1F839598B611@cs.ucla.edu>
	<CAF0tj-Yr63kdjC73kKdW2bq8Bw4QvT5xx6GX5YtsqjDdxbkh3Q@mail.gmail.com>
Message-ID: <0183256E-2428-4049-AE38-8613613D7F3C@cs.ucla.edu>


> On Jan 14, 2016, at 8:26 PM, Hugh Edwards <hughedwards94 at gmail.com> wrote:
> 
> That was exactly what I was looking for, thank you.
> I'm still curious about the scenario that I mentioned about ChronoSync / broadcasting / partitioning. 

Chronosync assumes that (1) there is a route to each participant of a particular Chronosync session (room) (2) routers perform `smart flooding? in a sense that packet is forwarded not to all physical interfaces, but to all interfaces of a particular FIB entry.

Overall, it is a huge limitation and many people do not believe that Chronosync is a practical protocol.  

> 
> I was also wondering if there were any apps available (perhaps even compatible with the latest version of NFD) that utilise any of the strategies mentioned in the article? 
You mean web-patterns? They are not built-in, but some of them could be implemented over Consumer/Producer API. For details, see Section 6.4 in http://escholarship.org/uc/item/17c660bp

> I bookmarked a modified ndn-cxx library 'consumer-producer api' that I recall was developed for this purpose... Looking back at that page I notice it's hosted on your GitHub page so I guess I'm asking the right person.

This repo will be updated soon.

Ilya

> 
> Thanks,
> Hugh. 
> 
> On Fri, Jan 15, 2016 at 8:54 AM, Ilya Moiseenko <iliamo at cs.ucla.edu <mailto:iliamo at cs.ucla.edu>> wrote:
> There is a paper about web interaction over NDN talking about the issues you mentioned
> http://conferences2.sigcomm.org/acm-icn/2014/papers/p87.pdf <http://conferences2.sigcomm.org/acm-icn/2014/papers/p87.pdf>
> 
> Ilya
> 
>> On Jan 14, 2016, at 5:19 PM, Hugh Edwards <hughedwards94 at gmail.com <mailto:hughedwards94 at gmail.com>> wrote:
>> 
>> Hi all,
>> 
>> I'm quite new to NDN, but I think beginning to get the hang of it.
>> One thing I'm getting stuck on understanding is how NDN supports pushed data, or peer to peer communication. My understanding is that NDN eventually aims to replace IP, rather than be used in conjunction with it so this type of communication must be supported.
>> 
>> Basically I'm having trouble with the following:
>> For a client to send data to a server, it is possible to embed data in the Interest (much like a HTTP GET request) which could be sent to a unique prefix identifiable to a registered user on a website, for example. Is it possible to guarantee the Interest will reach the server through having the returned Data having a very brief freshness period?
>> 
>> That would work well for small amounts of data but for a file upload for example, I imagine embedding that would be unwieldy and not conform to the NDN convention.
>> However, to send a file otherwise would require (as far as I understand):
>> -The user sends an Interest to a reserved prefix which is guaranteed to reach the server
>> -The server responds with an ACK (implementation specific, perhaps unnecessary) 
>> -The server sends an Interest to the user, as a go-ahead to send some data 
>> -User responds to that Interest with the Data they initially wished to send
>> 
>> I don't understand in this instance how the server would be able to route the data to the client, unless the client itself had a unique registered prefix which it embedded within the initial Interest. And if that were the case would that require every user to have a routable prefix which would lead to their PC?
>> 
>> ----
>> 
>> Secondly in regards to the synchronisation method of facilitating pushed-type data:
>> in the ChronoSync paper (of ChronoChat) it seems that it requires a specific prefix which utilises the broadcast strategy to effectively communicate the state to all nodes. If multiple applications wished to use their own broadcast prefix to use this type of synchronisation, would that then require router configuration (presumably automatically) to have the prefix registered and propagated such that other routers knew where to send Data? And on an Internet scale, if a router didn't broadcast on this prefix (it seems application specific, so only local routers would be configured to broadcast for this) but instead used a best-route strategy, would that then cause a network partition? How is it guaranteed that the synchronisation method will reach all users requesting it?
>> 
>> I hope these questions make sense, and I realise they may be based on a fundamental misunderstanding of the protocol. 
>> Sorry for the wall of text :) 
>> 
>> Thanks in advance,
>> Hugh. 
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu <mailto:Ndn-interest at lists.cs.ucla.edu>
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest <http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160121/5f53a188/attachment.html>

From jp at wustl.edu  Mon Jan 25 08:46:24 2016
From: jp at wustl.edu (Jyoti Parwatikar)
Date: Mon, 25 Jan 2016 10:46:24 -0600
Subject: [Ndn-interest] using ValidatorConfig
In-Reply-To: <EA870886-01D7-4E4E-B355-796BD048F91B@email.arizona.edu>
References: <56991C63.7050404@wustl.edu>
	<2795B60D-3C1D-4FDF-8A02-A2B078244AEE@email.arizona.edu>
	<56993894.8030406@wustl.edu>
	<EA870886-01D7-4E4E-B355-796BD048F91B@email.arizona.edu>
Message-ID: <56A65160.4090303@wustl.edu>

Hi Junxiao,

I just got back to working on this.
I suspect my certificate is probably incorrect. When I step through the 
code, it is failing to create the IdentityCertificate from the file in  
ndn::security::conf::CheckerFactory::getSigner(const ConfigSection&, 
const string&)
I can see it read in from the configuration file and it's reading the 
other parameters fine. It's failing when it hits the creation of the 
signer in the checker.

The process is run as me. And the certificate file has permission 644.
First line of certificate file: 
Bv0C1QczCAV3dXN0bAgDS0VZCBFkc2stMTQ1Mjg3Mjk2ODQ2OAgHSUQtQ0VSVAgJ

My configuration file:
rule
{
    id "h1x1 data rule"
    for data
    filter
    {
       type name
       name /wustl/CHRONOLOG
       relation is-prefix-of
    }
    checker
    {
       type fixed-signer
       sig-type rsa-sha256
       signer
       {
          type file
          file-name "/users/jp/ndn/JPChronolog/cfg-files/wustl.cert"
       }
    }
}

-Jyoti


On 01/15/2016 12:20 PM, Junxiao Shi wrote:
> Hi Jyoti
>
> If giving the full path still doesn?t work, reply-all with the following:
>
>   * the complete ValidatorConfig configuration
>   * the code snippet that loads the configuration; in particular, is
>     it loaded from a file or from a string
>   * the full path of your certificate file
>   * the first line of your certificate file (this helps determining
>     whether you have the correct format in the certificate file)
>   * what is the current working directory
>   * what is the effective uid of the running program, and what Unix
>     permissions does this uid have on the certificate file
>
>
> Yours, Junxiao
>
>> On Jan 15, 2016, at 11:21 AM, Jyoti Parwatikar <jp at wustl.edu 
>> <mailto:jp at wustl.edu>> wrote:
>>
>> Junxiao,
>>
>> I am giving the full path.
>>
>> -Jyoti
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160125/324a8203/attachment.html>

From s.h.ahmed at ieee.org  Tue Jan 26 23:02:14 2016
From: s.h.ahmed at ieee.org (Syed Hassan Ahmed)
Date: Wed, 27 Jan 2016 16:02:14 +0900
Subject: [Ndn-interest] Chunk level Data Retrieval in mobile NDN
Message-ID: <CAJeX4qe5Uyc55YsSfbvEFQWZ=Shr5RE7Jh1KhTt7jER7Q_n1=g@mail.gmail.com>

Hello Dear Colleagues and Seniors,

I have a simple query regarding Chunk level retrieval in NDN enabled mobile
networks such as VANETs, MANETs, etc.

Let's consider one scenario:

We have a consumer (C), looking for an Interest (i), and the current
neighboring node (n) is not the provider of (i). In this case, the (n) will
forward the (i) depending on any forwarding strategy. Now lets say, the
very next hop to (n) is the provider (P) of (i) and the chunk level data
retrieval starts in multi-hop fashion. However, after the successful
delivery of few chunks (e.g. 5 out of 15 chunks), the (n) moves out between
the (C) and (P), given that we have always caching on.

What will happen to those 5 chunks cached in the memory of (n)? How they
can be used? And if not, is there any scheme or mechanism defined in the
current NDN to discard them? Or they will be discarded straight away?


Kind
?
 Regards,
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
*Syed Hassan Ahmed*
??? ?? ????

PhD Research Scholar,
MoNeT Wireless Lab, <http://monet.knu.ac.kr>
Kyungpook National University,
Daegu City, Republic of Korea.
Cell: +82-10-9883-0786
https://sites.google.com/site/shahmedknu/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160127/731bc110/attachment.html>

From aa at CS.UCLA.EDU  Tue Jan 26 23:13:29 2016
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Tue, 26 Jan 2016 23:13:29 -0800
Subject: [Ndn-interest] [NDN-TR] NDN-0037 revision 1: A Secure Link State
	Routing Protocol for NDN
Message-ID: <E89C4E4D-5CCC-4B75-BFCD-0BF4EC9B2277@cs.ucla.edu>

A new NDN Technical Report (initial revision) is now available on NDN website.
Comments and suggestions are highly welcome.

    Title         : A Secure Link State Routing Protocol for NDN
    Authors       : Vince Lehman, A K M Mahmudul Hoque, Yingdi Yu, Lan Wang,
                    Beichuan Zhang, and Lixia Zhang
    Number        : NDN-0037
    Revision      : 1
    Revision Date : 2016-01-26
    Obsoletes     : A. Hoque, S. O. Amin, A. Alyyan, B. Zhang, L. Zhang, and
                    L. Wang, NLSR: Named Data Link State routing protocol, in
                    Proceedings  of the 3rd ACM SIGCOMM Workshop on Information-
                    Centric Networking, 2013.

Abstract:
    The Named-data Link State Routing protocol (NLSR) is an intra-domain routing
    protocol for Named Data Networking (NDN). It is an application level protocol
    similar to many IP routing protocols, but NLSR uses NDN?s Interest/Data packets
    to disseminate routing updates, directly benefiting from NDN?s built-in data
    authenticity. The initial NLSR design, which was developed in 2013, has
    undergone significant changes. The new NLSR has been deployed on the NDN testbed
    since August 2014; its development helped drive the development of the
    trust/security functionality of NDN libraries as well as a number of features in
    NFD and ChronoSync. In this paper, we describe the current design and
    implementation of NLSR, with emphasis on those features that differentiate it
    from an IP-based link state routing protocol ? (1) naming: a hierarchical naming
    scheme for routers, keys, and routing updates; (2) security: a hierarchical
    trust model for routing within a single administrative domain; (3) routing
    information dissemination: using ChronoSync to disseminate routing updates; and
    (4) multipath routing: a simple way to calculate and rank multiple forwarding
    options. Although NLSR is designed in the context of a single domain, its design
    patterns may offer a useful reference for future development of inter-domain
    routing protocols.

Information page for this TR:
    http://named-data.net/publications/techreports/ndn-0037-1-nlsr/

Direct link to PDF:
    http://named-data.net/wp-content/uploads/2016/01/ndn-0037-1-nlsr.pdf

Other NDN Technical Reports:
    http://named-data.net/publications/techreports/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160126/1b85f1b9/attachment.bin>

From 121049189 at qq.com  Thu Jan 28 05:51:52 2016
From: 121049189 at qq.com (=?gb18030?B?1dTWvs6w?=)
Date: Thu, 28 Jan 2016 21:51:52 +0800
Subject: [Ndn-interest] File transmission in NDN
Message-ID: <tencent_0A3AAC1227C98D077FCEEC08@qq.com>

Dear all,
    I'm quiet new to NDN, but I beginning to get the hang of it.
In CCNx, I know there is some application instructions about the file of transmission such as ccnsendchunks, ccncatchunks. I wonder there is similar instructions in NDN.
    
  Thanks in advance.
------------------
----------------------------------------------------
???
?????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160128/ce54d483/attachment.html>

From hughedwards94 at gmail.com  Thu Jan 28 12:32:51 2016
From: hughedwards94 at gmail.com (Hugh Edwards)
Date: Fri, 29 Jan 2016 07:02:51 +1030
Subject: [Ndn-interest] File transmission in NDN
In-Reply-To: <tencent_0A3AAC1227C98D077FCEEC08@qq.com>
References: <tencent_0A3AAC1227C98D077FCEEC08@qq.com>
Message-ID: <CAF0tj-bPR_3bn-dbQp7_AjNsRv809p+Bt4oz4x5nOCV3BYYiYw@mail.gmail.com>

The best way I found was through reading the source for the Segment
Publisher class.
http://named-data.net/doc/NFD/0.3.2/doxygen/de/d1c/segment-publisher_8hpp_source.html


On Fri, Jan 29, 2016 at 12:21 AM, ??? <121049189 at qq.com> wrote:

> Dear all,
>     I'm quiet new to NDN, but I beginning to get the hang of it.
> In CCNx, I know there is some application instructions about the file of
> transmission such as ccnsendchunks, ccncatchunks. I wonder there is
> similar instructions in NDN.
>
>   Thanks in advance.
> ------------------
> ----------------------------------------------------
> ???
> ?????????????
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160129/525d4435/attachment.html>

From shijunxiao at email.arizona.EDU  Thu Jan 28 12:43:34 2016
From: shijunxiao at email.arizona.EDU (Junxiao Shi)
Date: Thu, 28 Jan 2016 13:43:34 -0700
Subject: [Ndn-interest] File transmission in NDN
In-Reply-To: <tencent_0A3AAC1227C98D077FCEEC08@qq.com>
References: <tencent_0A3AAC1227C98D077FCEEC08@qq.com>
Message-ID: <48C5A6FA-C1EC-4128-ACEA-49AA563925FE@email.arizona.edu>

Hi Zhiwei

This is just in: the equivalent of ccnsendchunks and ccncatchunks are ndnputchunks and ndncatchunks <https://github.com/named-data/ndn-tools/tree/master/tools/chunks>.

Yours, Junxiao

> On Jan 28, 2016, at 6:51 AM, ??? <121049189 at qq.com> wrote:
> 
> Dear all,
>     I'm quiet new to NDN, but I beginning to get the hang of it.
> In CCNx, I know there is some application instructions about the file of transmission such as ccnsendchunks, ccncatchunks. I wonder there is similar instructions in NDN.
>     
>   Thanks in advance.
> ------------------
> ----------------------------------------------------
> ???
> ?????????????
>  
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160128/2dcc837c/attachment.html>

From aa at CS.UCLA.EDU  Thu Jan 28 12:48:46 2016
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Thu, 28 Jan 2016 12:48:46 -0800
Subject: [Ndn-interest] File transmission in NDN
In-Reply-To: <CAF0tj-bPR_3bn-dbQp7_AjNsRv809p+Bt4oz4x5nOCV3BYYiYw@mail.gmail.com>
References: <tencent_0A3AAC1227C98D077FCEEC08@qq.com>
	<CAF0tj-bPR_3bn-dbQp7_AjNsRv809p+Bt4oz4x5nOCV3BYYiYw@mail.gmail.com>
Message-ID: <A77D2848-4A1D-44CE-B56A-4032965931DA@cs.ucla.edu>

There are several other examples on publishing and retrieving "files":

- "chunks" (ndncatchunks and ndnputchunks): a recent addition to NDN Essential Tools (https://github.com/named-data/ndn-tools <https://github.com/named-data/ndn-tools>)
- publishing with NDNFS (the most recent version of the code is here https://github.com/remap/ndnfs-port <https://github.com/remap/ndnfs-port>)
- ndnputfile and ndngetfile tools to publish/retrieve from repo (https://github.com/named-data/repo-ng/tree/master/tools <https://github.com/named-data/repo-ng/tree/master/tools>)

---
Alex

> On Jan 28, 2016, at 12:32 PM, Hugh Edwards <hughedwards94 at gmail.com> wrote:
> 
> The best way I found was through reading the source for the Segment Publisher class.
> http://named-data.net/doc/NFD/0.3.2/doxygen/de/d1c/segment-publisher_8hpp_source.html <http://named-data.net/doc/NFD/0.3.2/doxygen/de/d1c/segment-publisher_8hpp_source.html>
> 
> 
> On Fri, Jan 29, 2016 at 12:21 AM, ??? <121049189 at qq.com <mailto:121049189 at qq.com>> wrote:
> Dear all,
>     I'm quiet new to NDN, but I beginning to get the hang of it.
> In CCNx, I know there is some application instructions about the file of transmission such as ccnsendchunks, ccncatchunks. I wonder there is similar instructions in NDN.
> 
>   Thanks in advance.
> ------------------
> ----------------------------------------------------
> ???
> ?????????????

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160128/9d24870d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160128/9d24870d/attachment.bin>

From andrea.detti at uniroma2.it  Fri Jan 29 06:21:07 2016
From: andrea.detti at uniroma2.it (Andrea Detti)
Date: Fri, 29 Jan 2016 15:21:07 +0100
Subject: [Ndn-interest] File transmission in NDN
In-Reply-To: <A77D2848-4A1D-44CE-B56A-4032965931DA@cs.ucla.edu>
References: <tencent_0A3AAC1227C98D077FCEEC08@qq.com>
	<CAF0tj-bPR_3bn-dbQp7_AjNsRv809p+Bt4oz4x5nOCV3BYYiYw@mail.gmail.com>
	<A77D2848-4A1D-44CE-B56A-4032965931DA@cs.ucla.edu>
Message-ID: <56AB7553.4020906@uniroma2.it>

Be careful that ndngetfile follows a stop & wait approach (one 
Interest/Data at a time) with obviously very worse performance with 
respect to TCP/IP.

I do not know which are the Interest tx window strategies used by the 
other softwares.

My two cents.

Andrea



On 28/01/2016 21:48, Alex Afanasyev wrote:
> There are several other examples on publishing and retrieving "files":
>
> - "chunks" (ndncatchunks and ndnputchunks): a recent addition to NDN 
> Essential Tools (https://github.com/named-data/ndn-tools)
> - publishing with NDNFS (the most recent version of the code is here 
> https://github.com/remap/ndnfs-port)
> - ndnputfile and ndngetfile tools to publish/retrieve from repo 
> (https://github.com/named-data/repo-ng/tree/master/tools)
>
> ---
> Alex
>
>> On Jan 28, 2016, at 12:32 PM, Hugh Edwards <hughedwards94 at gmail.com 
>> <mailto:hughedwards94 at gmail.com>> wrote:
>>
>> The best way I found was through reading the source for the Segment 
>> Publisher class.
>> http://named-data.net/doc/NFD/0.3.2/doxygen/de/d1c/segment-publisher_8hpp_source.html
>>
>>
>> On Fri, Jan 29, 2016 at 12:21 AM, ??? <121049189 at qq.com 
>> <mailto:121049189 at qq.com>> wrote:
>>
>>     Dear all,
>>         I'm quiet new to NDN, but I beginning to get the hang of it.
>>     In CCNx, I know there is some application instructions about the
>>     file of transmission such as ccnsendchunks, ccncatchunks. I
>>     wonder there is similar instructions in NDN.
>>     Thanks in advance.
>>     ------------------
>>     ----------------------------------------------------
>>     ???
>>     ?????????????
>>
>
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160129/e337e247/attachment.html>

From josh at caida.org  Fri Jan 29 16:56:53 2016
From: josh at caida.org (Josh Polterock)
Date: Fri, 29 Jan 2016 16:56:53 -0800
Subject: [Ndn-interest] Named Data Networking (NDN) Project Monthly
 Newsletter for January 2016
Message-ID: <20160130005653.GB18328@caida.org>


Named Data Networking (NDN) Project Newsletter for January 2016

The NDN project team compiles and publishes this newsletter monthly
to inform the community about recent activities, technical news,
meetings, publications, presentations, code releases, and upcoming
events. You can find these newsletters posted on the Named Data
Networking Project blog.

TECHNICAL NEWS

* The NDN Testbed has grown to 31 Nodes with 84 links. Since our
  last newsletter, four new sites have connected to the NDN Testbed;
  University of Goettingen, University of Indonesia, Osaka University,
  and the University of Minho in Portugal. See the complete list
  at http://named-data.net/ndn-testbed/.

* We released version 0.4.0 of Named Data Networking Forwarding
  Daemon (NFD) and ndn-cxx library.  

  Please find detailed release notes: 
  NFD: http://named-data.net/doc/NFD/0.4.0/RELEASE_NOTES.html
  ndn-cxx library: http://named-data.net/doc/ndn-cxx/0.4.0/RELEASE_NOTES.html
  
  More details about NFD, source code, install instructions,
  tutorials, HOWTOs, a FAQ and other useful resources are available
  on the official webpages of NFD and ndn-cxx:
     - http://named-data.net/doc/NFD/0.4.0/
     - http://named-data.net/doc/ndn-cxx/0.4.0/     

* We announced the release of version 0.2.2 of Named Data Link State
  Routing Protocol (NLSR).  Detailed release notes can be found at:
  http://named-data.net/doc/NLSR/0.2.2/RELEASE-NOTES.html More
  information about NLSR, tutorials, installation and configuration
  guides, and other useful resources are available on the official
  webpage of NLSR: http://named-data.net/doc/NLSR/0.2.2/

* We published the *alpha* version of NFD on Android to Google Play
  store, based on the recently released NFD version 0.4.0. This
  first release has limited documentation. We welcome help in any
  form: bug reports and feature requests submitted to redmine
  (http://redmine.named-data.net/projects/nfd-android/issues),
  patches, bug fixes, feature implementations, documentation and
  updates.  To opt-in to the alpha testing and to download the NFD
  app, open https://play.google.com/apps/testing/net.named_data.nfd
  on your Android device.  Source code for the port is available
  on GitHub: https://github.com/named-data-mobile/NFD-android

NDN PUBLICATIONS, PRESENTATIONS, and TECHNICAL REPORTS

* NDN TR-0036 Revision 1: Wentao Shang, Yingdi Yu, Teng Liang,
  Beichuan Zhang, and Lixia Zhang. "NDN-ACE: Access Control for
  Constrained Environments over Named Data Networking" presents
  NDN-ACE, a lightweight access control protocol for constrained
  environments over Named Data Networking (NDN).
  http://named-data.net/publications/techreports/ndn-0036-1-ndn-ace/

* NDN TR-0037 Revision 1: Vince Lehman, A K M Mahmudul Hoque, Yingdi
  Yu, Lan Wang, Beichuan Zhang and Lixia Zhang. "A Secure Link State
  Routing Protocol for NDN" describes the Named-data Link State
  Routing protocol (NLSR), an intra-domain routing protocol for
  Named Data Networking (NDN).
  http://named-data.net/publications/techreports/ndn-0037-1-nlsr/

SEMINARS

* Our NDN Seminar series will continue this semester.  The NDN
  seminars are internally focused. We have a poll out to PIs to
  select the most popular time slot for presentations. If you would
  like to participate in the NDN Seminars, please contact the new
  PoC, UCLA PhD. candidate Spyridon Mastorakis
  <Spiros.mastorakis at gmail.com> for the most up-to-date information
  regarding upcoming seminars.

RELATED WORK

* University of Arizona PhD student, Junxiao Shi introduced
  NFD-Windows, Microsoft Windows builds of the NDN software.  This
  project started during the NDNcomm2015 hackathon. With the release 
  of NFD 0.4.0 with face refactoring, NDN builds and runs on Microsoft
  Windows.

  NFD-Windows currently offers the following programs: ndnsec, nfd,
  nfdc, nfd-status, ndnpeek, ndnpoke, ndnping, ndnpingserver,
  ndn-dissect, and infoedit.  For details and download, see
  https://yoursunny.com/p/NFD-Windows/.

For more information about the Named Data Networking (NDN) Project
please visit http://www.named-data.net/.




From shijunxiao at email.arizona.EDU  Sat Jan 30 07:47:13 2016
From: shijunxiao at email.arizona.EDU (Junxiao Shi)
Date: Sat, 30 Jan 2016 08:47:13 -0700
Subject: [Ndn-interest] using ValidatorConfig
In-Reply-To: <56A65160.4090303@wustl.edu>
References: <56991C63.7050404@wustl.edu>
	<2795B60D-3C1D-4FDF-8A02-A2B078244AEE@email.arizona.edu>
	<56993894.8030406@wustl.edu>
	<EA870886-01D7-4E4E-B355-796BD048F91B@email.arizona.edu>
	<56A65160.4090303@wustl.edu>
Message-ID: <56acdb01.132c620a.8cf2f.1fad@mx.google.com>

Hi Jyoti

Your certificate file and Unix permissions appear to be valid.

Can Yingdi have a look at this case?

Yours, Junxiao

From: Jyoti Parwatikar
Sent: Monday, January 25, 2016 09:46
To: Junxiao Shi
Cc: ndn-interest at lists.cs.ucla.edu
Subject: Re: [Ndn-interest] using ValidatorConfig

Hi Junxiao,

I just got back to working on this.
I suspect my certificate is probably incorrect. When I step through the code, it is failing to create the IdentityCertificate from the file in? ndn::security::conf::CheckerFactory::getSigner(const ConfigSection&, const string&) 
I can see it read in from the configuration file and it's reading the other parameters fine. It's failing when it hits the creation of the signer in the checker.

The process is run as me. And the certificate file has permission 644. 
First line of certificate file: Bv0C1QczCAV3dXN0bAgDS0VZCBFkc2stMTQ1Mjg3Mjk2ODQ2OAgHSUQtQ0VSVAgJ

My configuration file:
rule
{
?? id "h1x1 data rule"
?? for data
?? filter
?? {
????? type name
????? name /wustl/CHRONOLOG
????? relation is-prefix-of
?? }
?? checker
?? {
????? type fixed-signer
????? sig-type rsa-sha256
????? signer
????? {
???????? type file
???????? file-name "/users/jp/ndn/JPChronolog/cfg-files/wustl.cert"
????? }
?? }
}

-Jyoti

On 01/15/2016 12:20 PM, Junxiao Shi wrote:
Hi Jyoti 

If giving the full path still doesn?t work, reply-all with the following:
? the complete ValidatorConfig configuration
? the code snippet that loads the configuration; in particular, is it loaded from a file or from a string
? the full path of your certificate file
? the first line of your certificate file (this helps determining whether you have the correct format in the certificate file)
? what is the current working directory
? what is the effective uid of the running program, and what Unix permissions does this uid have on the certificate file

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160130/420a8ad1/attachment.html>

From yingdi at CS.UCLA.EDU  Sat Jan 30 23:28:31 2016
From: yingdi at CS.UCLA.EDU (Yingdi Yu)
Date: Sat, 30 Jan 2016 23:28:31 -0800
Subject: [Ndn-interest] using ValidatorConfig
In-Reply-To: <56acdb01.132c620a.8cf2f.1fad@mx.google.com>
References: <56991C63.7050404@wustl.edu>
	<2795B60D-3C1D-4FDF-8A02-A2B078244AEE@email.arizona.edu>
	<56993894.8030406@wustl.edu>
	<EA870886-01D7-4E4E-B355-796BD048F91B@email.arizona.edu>
	<56A65160.4090303@wustl.edu>
	<56acdb01.132c620a.8cf2f.1fad@mx.google.com>
Message-ID: <52C055D9-8D8D-4628-ACD1-4F907D627ED8@cs.ucla.edu>

Hi Jyoti,

Could you also share the error msg? You can get that be catch std::runtime_error around load() method, and the print out e.what(), e.g.,

try {
  validator.load(?);
}
catch (const std::runtime_error& e) {
  std::cerr << e.what() << std::endl;
}

The error message may help us to figure out what kind of error is detected. Thanks!

Yingdi




> On Jan 30, 2016, at 7:47 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Hi Jyoti
>  
> Your certificate file and Unix permissions appear to be valid.
>  
> Can Yingdi have a look at this case?
>  
> Yours, Junxiao
> 
> From: Jyoti Parwatikar <mailto:jp at wustl.edu>
> Sent: Monday, January 25, 2016 09:46
> To: Junxiao Shi <mailto:shijunxiao at email.arizona.edu>
> Cc: ndn-interest at lists.cs.ucla.edu <mailto:ndn-interest at lists.cs.ucla.edu>
> Subject: Re: [Ndn-interest] using ValidatorConfig
>  
> Hi Junxiao,
> 
> I just got back to working on this.
> I suspect my certificate is probably incorrect. When I step through the code, it is failing to create the IdentityCertificate from the file in  ndn::security::conf::CheckerFactory::getSigner(const ConfigSection&, const string&) 
> I can see it read in from the configuration file and it's reading the other parameters fine. It's failing when it hits the creation of the signer in the checker.
> 
> The process is run as me. And the certificate file has permission 644. 
> First line of certificate file: Bv0C1QczCAV3dXN0bAgDS0VZCBFkc2stMTQ1Mjg3Mjk2ODQ2OAgHSUQtQ0VSVAgJ
> 
> My configuration file:
> rule
> {
>    id "h1x1 data rule"
>    for data
>    filter
>    {
>       type name
>       name /wustl/CHRONOLOG
>       relation is-prefix-of
>    }
>    checker
>    {
>       type fixed-signer
>       sig-type rsa-sha256
>       signer
>       {
>          type file
>          file-name "/users/jp/ndn/JPChronolog/cfg-files/wustl.cert"
>       }
>    }
> }
> 
> -Jyoti
> 
> 
> On 01/15/2016 12:20 PM, Junxiao Shi wrote:
> Hi Jyoti
>  
> If giving the full path still doesn?t work, reply-all with the following:
> the complete ValidatorConfig configuration
> the code snippet that loads the configuration; in particular, is it loaded from a file or from a string
> the full path of your certificate file
> the first line of your certificate file (this helps determining whether you have the correct format in the certificate file)
> what is the current working directory
> what is the effective uid of the running program, and what Unix permissions does this uid have on the certificate file
>  
> Yours, Junxiao

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160130/973b44bc/attachment.html>

From nano at remap.UCLA.EDU  Sun Jan 31 18:33:24 2016
From: nano at remap.UCLA.EDU (Alex Horn)
Date: Sun, 31 Jan 2016 20:33:24 -0600
Subject: [Ndn-interest] File transmission in NDN
In-Reply-To: <56AB7553.4020906@uniroma2.it>
References: <tencent_0A3AAC1227C98D077FCEEC08@qq.com>
	<CAF0tj-bPR_3bn-dbQp7_AjNsRv809p+Bt4oz4x5nOCV3BYYiYw@mail.gmail.com>
	<A77D2848-4A1D-44CE-B56A-4032965931DA@cs.ucla.edu>
	<56AB7553.4020906@uniroma2.it>
Message-ID: <CALqQCKtrpUFQztmOJVbegVoxpvUK7Z1aAgr6n3HP8hNd11G57Q@mail.gmail.com>

On Fri, Jan 29, 2016 at 8:21 AM, Andrea Detti <andrea.detti at uniroma2.it>
wrote:

> Be careful that ndngetfile follows a stop & wait approach (one
> Interest/Data at a time) with obviously very worse performance with respect
> to TCP/IP.
>

though note ndngetfile is a demonstration.
once familiar w/ NDN, applications can of course do better.


> I do not know which are the Interest tx window strategies used by the
> other softwares.
>

see ndn-rtc (
http://named-data.net/publications/ndn-rtc_real_time_videoconferencing/)
for recent example of interest pipelining in service of N-user a/v
conferencing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160131/3790cd16/attachment.html>