[Mini-NDN] Fwd: Minindn issues

amulya amy ammu.amulya12 at gmail.com
Tue Apr 10 00:55:25 PDT 2018


---------- Forwarded message ---------
From: amulya amy <ammu.amulya12 at gmail.com>
Date: Tue, Apr 10, 2018, 11:49 AM
Subject: Re: [Mini-NDN] Minindn issues
To: Junxiao Shi <shijunxiao at email.arizona.edu>


Is there any means of knowing that the content is returned from on-path
caching instead of original server?

On Tue, Apr 10, 2018 at 11:47 AM, amulya amy <ammu.amulya12 at gmail.com>
wrote:

> If the data is returned from the nearest on-path cache then atleast RTT
> time should be minimum.. hope am making sense..
>
> On Tue, Apr 10, 2018 at 11:29 AM, Junxiao Shi <
> shijunxiao at email.arizona.edu> wrote:
>
>> Hi Amulya
>>
>> In-network cache is a major benefit of NDN protocol. You don’t need to
>> care where the Data comes from. The network will return it from the nearest
>> on-path cache when consumer asks for the same content.
>> If consumer asks for different content (different Interest names), they
>> will have to come from the origin server.
>>
>> Yours, Junxiao
>>
>> On Tue, Apr 10, 2018 at 01:55 amulya amy <ammu.amulya12 at gmail.com> wrote:
>>
>>> Hello sir,
>>> I am running Minindn with default topology and i have advertised name
>>> prefix on node d and requesting the advertised name prefix from node a... i
>>> am able to access the content, but second time when i repeat the same
>>> thing, i have to get the content from node b instead of getting content
>>> from node d because enroute it will be saved on each intermediate
>>> node...how to ensure that the content am getting back is from which node?.
>>> please help
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/mini-ndn/attachments/20180410/d7725c40/attachment.html>


More information about the Mini-NDN mailing list