[Ndn-lib] Transport Access From Face

Burke, Jeff jburke at remap.UCLA.EDU
Wed Feb 18 16:12:03 PST 2015


*doesn't

From: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Date: Thu, 19 Feb 2015 00:11:30 +0000
To: Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Cc: "ndn-lib at lists.cs.ucla.edu<mailto:ndn-lib at lists.cs.ucla.edu>" <ndn-lib at lists.cs.ucla.edu<mailto:ndn-lib at lists.cs.ucla.edu>>
Subject: Re: [Ndn-lib] Transport Access From Face

It does seem necessary in Andrew's case but I agree with this. Can you / have you opened a redmine issue?
Jeff

From: Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Date: Wed, 18 Feb 2015 16:08:10 -0800
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: Jeff Thompson <jefft0 at remap.UCLA.EDU<mailto:jefft0 at remap.UCLA.EDU>>, "Brown, Andrew" <andrew.brown at intel.com<mailto:andrew.brown at intel.com>>, "ndn-lib at lists.cs.ucla.edu<mailto:ndn-lib at lists.cs.ucla.edu>" <ndn-lib at lists.cs.ucla.edu<mailto:ndn-lib at lists.cs.ucla.edu>>
Subject: Re: [Ndn-lib] Transport Access From Face

Regardless the communication model (pushing unsolicited or solicited data), Face must expose some “put” method.

I have mentioned this many times in the past, exposing transport abstraction to applications and forcing applications to use to put “solicited data” is simply wrong.   It’s like using BSD sockets to receive connections and then creating raw packet (or libpcap) to send the responses.   Face should be the only layer between outside world and the applications.

---
Alex

On Feb 18, 2015, at 4:01 PM, Burke, Jeff <jburke at remap.UCLA.EDU<mailto:jburke at remap.UCLA.EDU>> wrote:

Andrew, will putting data in the MemoryContentCache and allowing it to respond "in the background" to interests work for you?  It's preferable to pushing unsolicited data.
Jeff

From: "Thompson, Jeff" <jefft0 at remap.UCLA.EDU<mailto:jefft0 at remap.UCLA.EDU>>
Date: Wed, 18 Feb 2015 22:15:35 +0000
To: "Brown, Andrew" <andrew.brown at intel.com<mailto:andrew.brown at intel.com>>
Cc: "ndn-lib at lists.cs.ucla.edu<mailto:ndn-lib at lists.cs.ucla.edu>" <ndn-lib at lists.cs.ucla.edu<mailto:ndn-lib at lists.cs.ucla.edu>>
Subject: Re: [Ndn-lib] Transport Access From Face

Correction: The OnInterest callback is porvided the Transport from the Face (same idea).

From: <Thompson>, Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Date: Wednesday, February 18, 2015 at 14:13
To: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>, "Brown, Andrew" <andrew.brown at intel.com<mailto:andrew.brown at intel.com>>
Cc: NDN Lib <ndn-lib at lists.cs.ucla.edu<mailto:ndn-lib at lists.cs.ucla.edu>>
Subject: Re: [Ndn-lib] Transport Access From Face

As Junxiao recommends, the in memory storage is available in the MemoryContentCache in the Common Client Libraries:
http://named-data.net/doc/ndn-ccl-api/memory-content-cache.html

This is being used in the C++ video conferencing app NdnCon.

Also, in the NDN design, the data packet should be returned on the same face which received the interest. This is why the face is provided in the OnInterest callback.  A simple application may have only one face and one registered prefix.  But if an application registers a prefix on multiple faces with the same OnInterest callback, then the callback should only send the data to the given face (where the interest came from).

- Jeff T

From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Wednesday, February 18, 2015 at 13:31
To: "Brown, Andrew" <andrew.brown at intel.com<mailto:andrew.brown at intel.com>>
Cc: NDN Lib <ndn-lib at lists.cs.ucla.edu<mailto:ndn-lib at lists.cs.ucla.edu>>
Subject: Re: [Ndn-lib] Transport Access From Face

Hi Andrew

I believe you are able to construct a Transport before creating the Face, and pass the Transport to the Face.
In this way, you have access to Transport outside of OnInterest callback.

However, after 2181<http://redmine.named-data.net/issues/2181>, NFD forwarder will reject all unsolicited Data.
Applications should make use of InMemoryStorage, and put Data into forwarder only after receiving an incoming Interest.

Yours, Junxiao

On Wed, Feb 18, 2015 at 2:26 PM, Brown, Andrew <andrew.brown at intel.com<mailto:andrew.brown at intel.com>> wrote:
As I understand it, a developer can push additional Data packets to a forwarder using the transport.send() method in the OnInterest callback (for caching, etc.). I would like to do this prior to any incoming Interests and would preferably like an API like face.push(data) to do it. Three questions:

-        Is there any way to do this currently outside of OnInterest and preserving a reference to Transport?

-        Is there any catch to using the content store in this way besides the fact that once it maxes out it will discard old Data packets?

-        Is this something to add to the client libraries or should it be in a class extending Face?


Sincerely,

Andrew Brown
Flex AST, IoTG Intelligent Solutions

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


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

_______________________________________________ Ndn-lib mailing list Ndn-lib at lists.cs.ucla.edu<mailto:Ndn-lib at lists.cs.ucla.edu> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-lib
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-lib/attachments/20150219/8cf65ed8/attachment.html>


More information about the Ndn-lib mailing list