Sunday, December 18, 2011

Network applications demos in coffeehouses

Preparing a demo in your office is stressful enough - the demo need to be tested and rehearsed again and again until the time of the demo itself. A demo of a network application is even more challenging because even in a controlled environment like an office you never know when a coworker will bring down the network by transferring huge files, or when a system admin will decide to do maintenance on a server at the same time (all real life examples, sadly). But there is nothing worse than having to demo a network application in a coffeehouse or a restaurant, which is, it seems, where 99% of these demo are done in the Bay Area. I did a lot of demos of a network application in such conditions in the last 18 months, without one single failure, so this blog entry will explain the environment I used, in the hope that it will be useful to someone else.

The WiFi in these places is generally slow and flaky, so the worst thing to do would be to use it. That's OK, I do not trust so-called experts to provide me a decent network, so why would I expect people whose job is to prepare a good cup of coffee to do better? Instead I used a laptop on which I installed the same software that is running in our data center, and I configured the laptop to be a WiFi Access Point. It was not the network application that was tailored to run on a special network (which would required to build an application that is different from the real product), it was my laptop that was simulating a very small instance of the Internet.

The first step was to find a Wifi adapter that could be used as a a Wifi Access Point (AP). I needed a adapter that is supported by the hostapd Debian package so I chose one from SIIG. The configuration of hostapd looks like this (/etc/hostapd/hostapd.conf):

wpa_key_mgmt=WPA-PSK WPA-EAP

The adapter needs an IP address, which is configured in /etc/network/interfaces:

allow-hotplug wlan1
iface wlan1 inet static

We need a DHCP server (package isc-dhcp-server) to allocate IP addresses to the devices that will connect to our AP (/etc/dhcp/dhcpd.conf):

subnet netmask {
  option routers;
  option domain-name-servers;

You can see here that the laptop will also be our DNS server. As I explained above we cannot depend on a connection to the real Internet, so we will have to also serve DNS requests. My favorite DNS server is djbdns so after installing the package I created a new tinydns instance (tinydns is the djbdns component that implements an authoritative DNS server):

$ tinydns-conf tinydns tinydns /etc/service/tinydns

The next step was to start tcpdump on the IP address of the AP to see what requests the network application will send. For each of them I needed to install the corresponding server and to add the DNS resource records in djbdns. For example the devices I used for the demo (Android Nexus One) need to synchronize with NTP, so I installed the ntp server so it is running on the AP (/etc/default/ntp):

NTPD_OPTS='-g -I wlan1'

Then I added the following lines in djbdns to redirect the devices to my NTP server (/etc/service/tinydns/root/data):

Finally because my demo devices were Android based, I printed the QR Code of the WiFi demo network and taped it directly on the Wifi adapter so the Android devices can be easily configured with the ZXing app.
Post a Comment