[Ndn-interest] Understanding push-type data
iliamo at CS.UCLA.EDU
Thu Jan 14 14:24:50 PST 2016
There is a paper about web interaction over NDN talking about the issues you mentioned
> On Jan 14, 2016, at 5:19 PM, Hugh Edwards <hughedwards94 at gmail.com> wrote:
> 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,
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ndn-interest