Network filesystems [LWN.net]

Network filesystems

Posted Oct 25, 2012 11:04 UTC (Thu) by epa (subscriber, #39769)
Parent article: Content-centric networking with CCNx

Back in the day I think Acorn's Econet network, often used in school classrooms, had a feature called the Broadcast Loader. When several computers requested the same file from the server, as often happens at the start of a lesson, it would notice and broadcast the file on the network for them all to receive simultaneously.

At first glance this looked like a similar thing, but on reading the article there isn't mention of IP multicasting or another way to avoid sending the same packet to several different recipients. Instead, it looks like a kind of distributed http cache or Bittorent. The load on the publishing server may be reduced, but global network traffic is just the same or greater. Surely the missing piece of the puzzle is a way for the response to be multicast to all those requesting it.

Streaming video seems like a bad example application since it is quite unsuited to the send-request-get-response model. The video stream is continuous; you don't request a frame at a time. And it is real-time, so you want as much predictibility as possibly in the route between you and the server so that the latency can be low and consistent. On the other hand, here we are talking about a Youtube-style recorded clip, which can be treated as a single file to download and then play.

(Log in to post comments)

Network filesystems

Posted Nov 3, 2012 15:57 UTC (Sat) by dmag (subscriber, #17775) [Link]

> Streaming video seems like a bad example application

Actually, that's a good example. In the past, people set up proprietary "video streaming servers" for this use case. Turns out, they don't scale, they are expensive, and they have lots of problems.

So people decided "what if we just used HTTP?" Apple made HLS (HTTP Live Streaming), and Adobe/Microsoft made similar knockoffs.

The idea was that any video (even live streams) can be encoded in chunks (usually 5s of video). Instead of a farm of specialized (and usually badly optimized) video streamers, you just use a farm of HTTP servers, copying in the segments as you go. The clients can benefit from HTTP caches, etc.

The same thing could work for CCNx: An intermediate node could forward one request for the next segment of the live stream, and satisfy multiple requesters. This may use more bandwidth at the edge (where it's usually not scarce) but the intermediate nodes will keep much less state. (I.e. once they satisfy the current segment, they keep no state until clients start requesting the next segment.)