Named Data Networking (NDN) is a potential future Internet architecture designed as a distribution network. To access the NDN network from a Linux or Apple OSX machine, one can install the NDN Platform, a collection of software packages including the protocol stack and critical applications. The NDN Forwarding Daemon (NFD), a core component of the architecture, serves as a software router and runs both on the network routers as well as on end hosts to communicate with routers.
The NDN team provides periodic releases of the new platform, and binary packages are provided with each platform release. However, the development of NDN software, including NFD, happens much faster than platform releases, so users can download source code from GitHub. If a user wants to run bleeding edge software, those packages must be built from source code.
As a geeky low end box user, I’m thinking: can I run the NDN platform on a Linux box with only a small amount of memory? The box I’m talking about is an OpenVZ container from LowEndSpirit UK location, with only 128MB memory and no swap space. To make the challenge more interesting, I want to avoid apt-get, and run the bleeding edge version built from source code.
Building the source code on the Low End Box
I quickly installed compilers and dependencies (such as libboost-all-dev which takes several minutes to download) with apt-get, and cloned the git repositories for NFD and other essential NDN Platform packages. Given that the box has small memory and slow CPU, I can expect the compilation process to take a few hours, just like 8 years ago when I was compiling Apache on a library computer.
The wait does not take too long: the build process ends after a few seconds, because it doesn’t work at all. ndn-cxx and NFD cannot build with only 128MB memory. You need 2GB memory of memory to build them from source. I can guess one reason is the extensive usage of Boost.Asio which involves lots of C++ templates, and gcc cannot handle all those identifiers within 128MB memory.
Cross-Compiling
Cross-compiling is a technique often used to build software for an embedded device with limited resources. For example, Android applications are not compiled on Android phones; instead, they are typically built on more powerful computers, and then loaded into the phones.
I can use the same technique to build NFD for the low end box: find a machine with more memory, and copy the binaries into the box. Except that, it’s unnecessary to cross-compile, because the box is x86 architecture, and it’s easy to find another machine with x86 architecture.
So, I provisioned an x86 virtual machine with 2GB memory on a powerful server. This machine must have the same operating system as the target box, and dependencies should have the same version. apt-get can keep the dependencies up to date. This means, each time I run a system update, I’d run it on both machines.
Now it follows the regular build process. I turned off all debugging options, because I don’t expect any useful debugging in 128MB memory.
Installation
Copying the binaries into the box turns out to be easy: Waf build system has a --destdir option which allows me to specify where to install the binaries. The default is / so that binaries are installed to the local machine.
All I need to do is to mount the root directory of the target box via sshfs, and specify
--destdir=/target. Alternatively, I can ask Waf to install into an empty directory, and then copy the contents onto the target box.
This process works. There’s still a problem: the binaries are huge, because they still contain some sort of debugging symbols. The solution is: run strip on each binary, after they are built but before installation.
Configuration
Hopefully NFD is up and running on the low end box now.
The default configuration comes optimized for a host with 1GB of memory and it keeps 500MB worth of packets in the cache. I don’t have 500MB of memory, so I lowered the tables.cs_max_packets configuration option.
Next Steps
Finally we have the software router running on the low end box. The next step would be to connect it to other routers, such as the NDN Testbed. I’ll cover this topic in the future.
Originally posted 2014-09-22 by Junxiao Shi. ©2014 yoursunny.com
Social tagging: apple > architevture > configuration > cross-compiling > daemon > deploy > distribution network > github > installation > linux > low end box > lowendspirit > ndn forwarding > ndn platform > ndn-cxx > network router > nfd > openvz > operating system > osx > protocal stack > software router > testbed