<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 23, 2014, at 1:10 AM, Haroon Rashid <<a href="mailto:haroonr@iiitd.ac.in" class="">haroonr@iiitd.ac.in</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><p class="MsoNormal">Thanks, Steve and Jeff for useful references. </p><p class="MsoNormal"><br class=""></p><p class="MsoNormal">First, I want to make it clear that I don’t have any
particular application in my mind right now. What all I am thinking of completely
<span id="4613e4fc-0e05-4cad-aed9-397772e5d4bd" class="GINGER_SOFTWARE_mark">unicast</span> communication in NDN in both directions (source->destination
&& destination->source), <i class="">i.e.</i>,
sort of end to end connection. I mean a <b class="">distributed
computing</b> type of application (not a lighting one). While going through the
paper (lighting), I found that we can communicate with the target machine using
its public key. This gives me an answer to one part of my question, but, now my
other issue is to differentiate the tasks from different machines. To make it
easy to understand let us use the following NDN network with 5 machines
connected via LAN. </p><div class=""><span style="margin-left:345px;margin-top:41px;width:36px;height:36px" class=""></span><span style="margin-left:157px;margin-top:97px;width:3px;height:32px" class=""></span><span style="margin-left:358px;margin-top:69px;width:3px;height:32px" class=""></span><span style="margin-left:281px;margin-top:97px;width:3px;height:32px" class=""></span><span style="margin-left:221px;margin-top:67px;width:3px;height:32px" class=""></span><span style="margin-left:92px;margin-top:65px;width:3px;height:34px" class=""></span><span style="margin-left:62px;margin-top:94px;width:363px;height:5px" class=""></span><span style="margin-left:269px;margin-top:128px;width:36px;height:36px" class=""></span><span style="margin-left:142px;margin-top:127px;width:36px;height:36px" class=""></span><span style="margin-left:207px;margin-top:38px;width:36px;height:35px" class=""></span><span style="margin-left:79px;margin-top:36px;width:36px;height:35px" class=""></span> <br class="webkit-block-placeholder"></div><p class="MsoNormal"> <span id="cid:ii_1493b655463bc25c"><Network.JPG></span></p><div class=""> <br class="webkit-block-placeholder"></div><p class="MsoNormal"> Now suppose both “B” and “D” need some computational results
from “C” and hence accordingly sent the interest packet containing public key
of “C” so that only C (not A or E) can act on the Interest packet. Therefore, “C”
has received interests and did some computations and now it needs to send back computational
results to “B” and “D” only. Now, accordingly these results should<span id="ff925124-97ab-420f-b549-25c7a77e76b0" class="GINGER_SOFTWARE_mark"> be unicas</span>ted
back by using the public keys of B and D. But, “C” does not know anything about these (B and
D) because interest packet from “B and D”
to “C” does not contain any information
about their origin. So, I want to know
how “C” will send speci<span id="859b2a06-ac2b-4508-a243-b858e7d8be41" class="GINGER_SOFTWARE_mark">fic resul</span>ts back
to these respective machines.</p><div class=""><br class="webkit-block-placeholder"></div></div></div></blockquote><div><br class=""></div><div>How important is it for B and D to be the only possible recipients? If it’s ok for others to receive the response (e.g. cache hit for a future request from A), then I don’t think you need to worry about encrypting the response.</div><div><br class=""></div><div>If you need B and D to be the unique recipients of their respective requests (B can’t read D’s response and vice versa), then you will want to encrypt. However, you don’t need B or D’s public key for this. Instead, B and D should provide a symmetric key to C as part of the computation request (i.e. encrypt the symmetric key towards C and place in a name component).</div><div><br class=""></div><div>We used this basic technique implementing ANDaNA (NDN Tor). There’s also a session-based version so that future requests use symmetric keys exclusively (encrypting towards C and the response). See: <a href="http://www.internetsociety.org/andana-anonymous-named-data-networking-application" class="">http://www.internetsociety.org/andana-anonymous-named-data-networking-application</a> </div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><p class="MsoNormal">I know that pending interests in PIT of “C” and in-between
routers might help but still I am not quite confident that it will work
successfully. This is because in the Interest packet I used Selectors part to
reach “C” , while as in the Data packet I don’t find any such field to specify
specific origin machines (B or D). Can anyone help me in the understanding of the same or point out to some references from where I can understand the same.</p></div></div></blockquote><div><br class=""></div>First and foremost, so long as the PIT entry is present, B and D will get a Data packet back (assuming the computation finishes in time, etc…). If B and D use the exact same Interest, then the PIT entry will have an appropriate set of face records that tells the node where to relay the returning Data. The same thing happens if B and D use different Interests, except there’s now one PIT entry for each with their respective face records.</div><div><br class=""></div><div>Selectors don’t change this. In fact, selectors are not used for routing the Interests to C in the first place. The selector’s job is to further specify the requested Data (“select something”) when there are one or more options (e.g. in a CS or repo) and determining which PIT entries can be satisfied by a returning Data packet.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> <br class="webkit-block-placeholder"></div><p class="MsoNormal">T<span id="7981133f-ccb4-496e-a547-6ec5bf1c9407" class="GINGER_SOFTWARE_mark">hanking you, </span> </p><div class=""> <br class="webkit-block-placeholder"></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Oct 23, 2014 at 1:29 AM, Burke, Jeff <span dir="ltr" class=""><<a href="mailto:jburke@remap.ucla.edu" target="_blank" class="">jburke@remap.ucla.edu</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap: break-word; font-size: 14px; font-family: Calibri, sans-serif;" class="">
<div class=""><br class="">
</div>
<div class="">I agree with Steve – the cases in the publications he sites are pretty specific, and are actually about targeting a physical object (light) not a computing node. We could make suggestions if you could describe the application.</div>
<div class="">Jeff</div>
<div class=""><br class="">
</div>
<span class="">
<div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);" class="">
<span style="font-weight:bold" class="">From: </span>Steve DiBenedetto <<a href="mailto:dibenede@cs.colostate.edu" target="_blank" class="">dibenede@cs.colostate.edu</a>><br class="">
<span style="font-weight:bold" class="">Date: </span>Wed, 22 Oct 2014 09:42:34 -0400<br class="">
<span style="font-weight:bold" class="">To: </span>Haroon Rashid <<a href="mailto:haroonr@iiitd.ac.in" target="_blank" class="">haroonr@iiitd.ac.in</a>><br class="">
<span style="font-weight:bold" class="">Cc: </span>Nitinder Mohan <<a href="mailto:nitinder1369@iiitd.ac.in" target="_blank" class="">nitinder1369@iiitd.ac.in</a>>, "<<a href="mailto:nfd-dev@lists.cs.ucla.edu" target="_blank" class="">nfd-dev@lists.cs.ucla.edu</a>>" <<a href="mailto:nfd-dev@lists.cs.ucla.edu" target="_blank" class="">nfd-dev@lists.cs.ucla.edu</a>>,
Pushpendra Singh <<a href="mailto:psingh@iiitd.ac.in" target="_blank" class="">psingh@iiitd.ac.in</a>>, "<a href="mailto:ndn-app@lists.cs.ucla.edu" target="_blank" class="">ndn-app@lists.cs.ucla.edu</a>" <<a href="mailto:ndn-app@lists.cs.ucla.edu" target="_blank" class="">ndn-app@lists.cs.ucla.edu</a>><br class="">
<span style="font-weight:bold" class="">Subject: </span>Re: [Nfd-dev] Unicast communication in a distributed application in NDN paradigm<br class="">
</div><div class=""><div class="h5">
<div class=""><br class="">
</div>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5" class="">
<div class="">
<div style="word-wrap:break-word" class="">
Hi,
<div class=""><br class="">
</div>
<div class="">I have not read these specific papers, but I recall their topics being similar to what you’re after:</div>
<div class=""><br class="">
</div>
<div class=""><a href="http://named-data.net/wp-content/uploads/nomen13.pdf" target="_blank" class="">http://named-data.net/wp-content/uploads/nomen13.pdf</a></div>
<div class=""><a href="http://named-data.net/wp-content/uploads/TRlighting.pdf" target="_blank" class="">http://named-data.net/wp-content/uploads/TRlighting.pdf</a></div>
<div class=""><br class="">
</div>
<div class="">In the past, I think we (the project) have discussed how NDN provides a superset of IP’s capabilities. If you really need point to point, there are mechanisms to get there. As you suggested, using a name that uniquely identifies an endpoint is
something in that direction. Encrypting the Interest’s name and the Data response can further lock things down.</div>
<div class=""><br class="">
</div>
<div class="">**However**, it sounds like you are questioning whether or not this is the communication model you really want. We may be able to offer some suggestions if you can describe the application.</div>
<div class=""><br class="">
</div>
<div class="">-Steve</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Oct 22, 2014, at 7:16 AM, Haroon Rashid <<a href="mailto:haroonr@iiitd.ac.in" target="_blank" class="">haroonr@iiitd.ac.in</a>> wrote:</div>
<br class="">
<div class="">
<div dir="ltr" class="">
<div class="">Hello All,</div>
<div class=""><br class="">
</div>
I am planning to develop a distributed application using NDN paradigm. In this application, each machine should be able to do
<span class="">unicast</span> communication and should not use shared memory (like
<span class="">ccnsync</span>/<span class="">chronosync</span>). If I am correct, we already have a distributed NDN-chat application
which is of broadcast nature (because message written in a namespace gets broadcasted to all members in the same namespace) and hence it uses the shared memory concept. Is there any other distributed application in NDN where
<span class="">unicast</span> communication is supported? If not, how Can I achieve the same in NDN? Should I put the name of the target machine in the Interest packet (name) itself for facilitating
such communication? But, would that will not change the basic architecture of NDN/CCN paradigm?<br clear="all" class="">
<div class=""><br class="">
</div>
-- <br class="">
<div dir="ltr" class="">
<div class="">
<div class="">Haroon Rashid<br class="">
</div>
<br class="">
</div>
<br class="">
</div>
</div>
_______________________________________________<br class="">
Nfd-dev mailing list<br class="">
<a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank" class="">Nfd-dev@lists.cs.ucla.edu</a><br class="">
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank" class="">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
_______________________________________________ Nfd-dev mailing list <a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank" class="">
Nfd-dev@lists.cs.ucla.edu</a> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank" class="">
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a> </blockquote>
</div></div></span>
</div>
</blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class=""><div class=""><div class="">Haroon Rashid<br class=""></div><br class=""></div><br class=""></div>
</div>
</div></blockquote></div><br class=""></body></html>