[Ndn-interest] Understanding push-type data

Hugh Edwards hughedwards94 at gmail.com
Thu Jan 14 17:26:15 PST 2016


That was exactly what I was looking for, thank you.
I'm still curious about the scenario that I mentioned about ChronoSync /
broadcasting / partitioning.

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?
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.

Thanks,
Hugh.

On Fri, Jan 15, 2016 at 8:54 AM, Ilya Moiseenko <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
>
> Ilya
>
> 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,
> Hugh.
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160115/38937d93/attachment.html>


More information about the Ndn-interest mailing list