[Ndn-interest] Understanding push-type data
iliamo at CS.UCLA.EDU
Thu Jan 21 08:21:17 PST 2016
> On Jan 14, 2016, at 8:26 PM, Hugh Edwards <hughedwards94 at gmail.com> wrote:
> That was exactly what I was looking for, thank you.
> I'm still curious about the scenario that I mentioned about ChronoSync / broadcasting / partitioning.
Chronosync assumes that (1) there is a route to each participant of a particular Chronosync session (room) (2) routers perform `smart flooding’ in a sense that packet is forwarded not to all physical interfaces, but to all interfaces of a particular FIB entry.
Overall, it is a huge limitation and many people do not believe that Chronosync is a practical protocol.
> I was also wondering if there were any apps available (perhaps even compatible with the latest version of NFD) that utilise any of the strategies mentioned in the article?
You mean web-patterns? They are not built-in, but some of them could be implemented over Consumer/Producer API. For details, see Section 6.4 in http://escholarship.org/uc/item/17c660bp
> I bookmarked a modified ndn-cxx library 'consumer-producer api' that I recall was developed for this purpose... Looking back at that page I notice it's hosted on your GitHub page so I guess I'm asking the right person.
This repo will be updated soon.
> On Fri, Jan 15, 2016 at 8:54 AM, Ilya Moiseenko <iliamo at cs.ucla.edu <mailto:iliamo at cs.ucla.edu>> wrote:
> There is a paper about web interaction over NDN talking about the issues you mentioned
> http://conferences2.sigcomm.org/acm-icn/2014/papers/p87.pdf <http://conferences2.sigcomm.org/acm-icn/2014/papers/p87.pdf>
>> On Jan 14, 2016, at 5:19 PM, Hugh Edwards <hughedwards94 at gmail.com <mailto: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 <mailto:Ndn-interest at lists.cs.ucla.edu>
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest <http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ndn-interest