Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Content-centric networking with CCNx

Posted Oct 25, 2012 9:37 UTC (Thu) by rswarbrick (subscriber, #47560)
Parent article: Content-centric networking with CCNx

I'm struggling to understand this. What, fundamentally, is different between a box on the network to make CCNx work and a caching proxy? Have I missed the point?

(Log in to post comments)

Posted Oct 25, 2012 11:24 UTC (Thu) by etienne (subscriber, #25256) [Link]

> What, fundamentally, is different between a box on the network to make CCNx work and a caching proxy?

Seems that you tell louder "what you want" and quieter (or not at all) "where you want it from".
Seems that PC doing CCNx would most of the time be clients *and* server.
So if a remote X connection needs a font to display some text, it would ask for the font file over CCNx, not ask the (maybe very distant) X server to provide the font file.
If a PC needs a file (package update, desktop background photo, ...) it asks over CCNx the file (giving its name, its version, some more info which identify uniquely what it wants - maybe the original reference server) and the nearest PC which has that file replies.

Content-centric networking with CCNx

Posted Oct 25, 2012 12:40 UTC (Thu) by rswarbrick (subscriber, #47560) [Link]

Ok, but if you want this to scale, you need some sort of unique ID for your document. There's the GUID approach, but that's not human-writable in the slightest. The other option is something heirarchical, where different content producers take bits of the total namespace. Of course, this is what people call a URL... (Or at least a URI)

I'm still massively not convinced that there's anything nontrivial here. I should probably go and have a careful look at ccnx.org and see if I can work out what they're doing. (and why)

Content-centric networking with CCNx

Posted Oct 25, 2012 14:13 UTC (Thu) by n8willis (editor, #43041) [Link]

Caching is predicated on the notion that there is one canonical version of the file, and the various cached versions are copies. In CCN, all versions of the file are equivalent (assuming the SHA-256 hash validates, that is). In HTTP, an end node could always request the original directly from the server if it doesn't trust the cache, but in CCN that gains you nothing since you can verify the correctness of the data yourself with the signature; consequently there is no mechanism to do so. Perhaps more importantly, intermediate nodes do not need to perform age calculations or any of the other cache-control mechanics.

Nate

Content-centric networking with CCNx

Posted Oct 25, 2012 14:46 UTC (Thu) by rswarbrick (subscriber, #47560) [Link]

Ah, I think I understand you. So the equivalent with an HTTP cache would require that (a) The contents at a given URL never changed and (b) The URL somehow also gave a hash of the contents so that you could check you'd got the right thing.

Yep, I agree that this is different from a caching proxy :-)