[Ndn-interest] Understanding push-type data

Hugh Edwards hughedwards94 at gmail.com
Thu Jan 14 14:19:57 PST 2016


Hi all,

I'm quite new to NDN, but I think beginning to get the hang of it.
One thing I'm getting stuck on understanding is how NDN supports pushed
data, or peer to peer communication. My understanding is that NDN
eventually aims to replace IP, rather than be used in conjunction with it
so this type of communication must be supported.

Basically I'm having trouble with the following:
For a client to send data to a server, it is possible to embed data in the
Interest (much like a HTTP GET request) which could be sent to a unique
prefix identifiable to a registered user on a website, for example. Is it
possible to guarantee the Interest will reach the server through having the
returned Data having a very brief freshness period?

That would work well for small amounts of data but for a file upload for
example, I imagine embedding that would be unwieldy and not conform to the
NDN convention.
However, to send a file otherwise would require (as far as I understand):
-The user sends an Interest to a reserved prefix which is guaranteed to
reach the server
-The server responds with an ACK (implementation specific, perhaps
unnecessary)
-The server sends an Interest to the user, as a go-ahead to send some data
-User responds to that Interest with the Data they initially wished to send

I don't understand in this instance how the server would be able to route
the data to the client, unless the client itself had a unique registered
prefix which it embedded within the initial Interest. And if that were the
case would that require every user to have a routable prefix which would
lead to their PC?

----

Secondly in regards to the synchronisation method of facilitating
pushed-type data:
in the ChronoSync paper (of ChronoChat) it seems that it requires a
specific prefix which utilises the broadcast strategy to effectively
communicate the state to all nodes. If multiple applications wished to use
their own broadcast prefix to use this type of synchronisation, would that
then require router configuration (presumably automatically) to have the
prefix registered and propagated such that other routers knew where to send
Data? And on an Internet scale, if a router didn't broadcast on this prefix
(it seems application specific, so only local routers would be configured
to broadcast for this) but instead used a best-route strategy, would that
then cause a network partition? How is it guaranteed that the
synchronisation method will reach all users requesting it?

I hope these questions make sense, and I realise they may be based on a
fundamental misunderstanding of the protocol.
Sorry for the wall of text :)

Thanks in advance,
Hugh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160115/4e2fb359/attachment.html>


More information about the Ndn-interest mailing list