[Nfd-dev] Unicast communication in a distributed application in NDN paradigm

Haroon Rashid haroonr at iiitd.ac.in
Wed Oct 22 22:10:02 PDT 2014


Thanks, Steve and Jeff for useful references.


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 unicast
communication in NDN in both directions (source->destination &&
destination->source), *i.e.*, sort of end to end connection. I mean a
*distributed
computing* 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.



                                      [image: Inline image 1]



 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 be unicasted 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  specific results back to these respective
machines.


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.



Thanking you,



On Thu, Oct 23, 2014 at 1:29 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:

>
>  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.
> Jeff
>
>   From: Steve DiBenedetto <dibenede at cs.colostate.edu>
> Date: Wed, 22 Oct 2014 09:42:34 -0400
> To: Haroon Rashid <haroonr at iiitd.ac.in>
> Cc: Nitinder Mohan <nitinder1369 at iiitd.ac.in>, "<nfd-dev at lists.cs.ucla.edu>"
> <nfd-dev at lists.cs.ucla.edu>, Pushpendra Singh <psingh at iiitd.ac.in>, "
> ndn-app at lists.cs.ucla.edu" <ndn-app at lists.cs.ucla.edu>
> Subject: Re: [Nfd-dev] Unicast communication in a distributed application
> in NDN paradigm
>
>   Hi,
>
>  I have not read these specific papers, but I recall their topics being
> similar to what you’re after:
>
>  http://named-data.net/wp-content/uploads/nomen13.pdf
> http://named-data.net/wp-content/uploads/TRlighting.pdf
>
>  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.
>
>  **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.
>
>  -Steve
>
>
>  On Oct 22, 2014, at 7:16 AM, Haroon Rashid <haroonr at iiitd.ac.in> wrote:
>
>  Hello All,
>
>  I am planning to develop a distributed application using NDN paradigm. In
> this application, each machine should be able to do unicast communication
> and should not use shared memory (like ccnsync/chronosync). 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 unicast
> 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?
>
>  --
>  Haroon Rashid
>
>
>  _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
>   _______________________________________________ Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>


-- 
Haroon Rashid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20141023/c6d80a88/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Network.JPG
Type: image/jpeg
Size: 12888 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20141023/c6d80a88/attachment.jpe>


More information about the Nfd-dev mailing list