[Ndn-lib] Transport Access From Face

Junxiao Shi shijunxiao at email.arizona.edu
Thu Feb 19 09:52:45 PST 2015


Dear folks

void Face::put(const Data& data) does not enforce flow balance: apps can
still put unsolicited Data into forwarder, which would be rejected after #
2181 <http://redmine.named-data.net/issues/2181>.


What about an alternative design:
struct Reply
{
  void operator()(const Data& data);
  void operator()(const Nack& nack);
};
typedef std::function<void(const Interest& interest, const Reply& reply)>
InterestCallback; // formerly OnInterest

The 'reply' function can be called only once; subsequent calls will raise
exceptions.
This could prevent apps from sending unsolicited Data.


Face::put can still be provided for sending unsolicited Data in special
cases, but it shall be named Face::putUnsolicitedData to warn developers.

Yours, Junxiao

On Thu, Feb 19, 2015 at 9:50 AM, Brown, Andrew <andrew.brown at intel.com>
wrote:

>  Jeff, Alex,
>
>
>
> Yes, in my case the MemoryContentCache will work. It fits 90% of what I
> needed and I can build the rest.
>
>
>
> As for Alex’s comment, I completely agree. To go from dealing with
> Data/Interest packets up at the Face level and suddenly to have to
> encode/decode bytes on a Transport inside an OnInterest callback seems to
> expose too much of the inner workings. It seems preferable the OnInterest
> signature to be onInterest(Name name, Interest interest, Face face, long
> registeredPrefixId) and only have to do a face.push(Data data) inside my
> callback. Is this basically what you are proposing, Alex? And if so, how
> does this work with Data signing?
>
>
>
> Sincerely,
>
>
>
> Andrew Brown
>
> Flex AST, IoTG Intelligent Solutions
>
> Cell: 360-292-5859
>
>
>
> *From: *Alex Afanasyev <alexander.afanasyev at ucla.edu>
> *Date: *Wed, 18 Feb 2015 16:08:10 -0800
> *To: *Jeff Burke <jburke at remap.ucla.edu>
> *Cc: *Jeff Thompson <jefft0 at remap.UCLA.EDU>, "Brown, Andrew" <
> andrew.brown at intel.com>, "ndn-lib at lists.cs.ucla.edu" <
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-lib/attachments/20150219/39585b90/attachment.html>


More information about the Ndn-lib mailing list