BonAHA: A Framework for Ad-Hoc Applications

Suman Srinivasan, Henning Schulzrinne

Internet Real Time Lab

Introduction

• Problem

• Approach– Service discovery and Bonjour– BonAHA framework

• Demos

• Related Work

Motivation

• Mobile nodes; highly mobile networks– No infrastructure

• OLPC; mesh networks– “Ad-hoc applications”– “Mobile P2P applications”

• Applications need to– Be aware of network transitions– State/metadata of nodes in the network

Background

• Started out with raw multicast

• Service discovery protocols– Apple’s Bonjour– Still requires a learning curve– Lots of repeated code

Bonjour API

• Factory class: DNSSD• Interfaces: Callback functions for events

– BrowseListener: Service browsing– ResolveListener: Name Resolution– RegisterListener: Service

Registration– QueryListener: DNS Record

Resolution– DomainListener: Domain Resolution

Bonjour API

• BrowseListener– serviceFound() when services appear– serviceLost() when service leaves

• ResolveListener: – serviceResolved() to get hostname, TXT

records

• RegisterListener: – serviceRegistered() when registration

succeeds (or fails)

Problems

• Bonjour API – Three listeners, five function calls– Have to be completely implemented if an ad-

hoc application wants to announce and listen

• Two other major problems– No internal state maintained by Bonjour for

services, related IP address and TXT records– Resolution can be done only on arrival or exit of

services

BonAHA

• Aim to make a framework that solves these problems

• Much simpler, and more intuitive, API for ad-hoc applications

• Applications need not maintain state or do “resolution”– BonAHA will maintain state– No need for resolution; all nodes and

metadata are objects

BonAHA• For registration

service = new BService("7ds_location2", "tcp");

service.set("Latitude", lat);service.set("Longitude", lon);service.register();service.setListener(this);

• For network transitions (nodes entering/leaving)– nodeUpdated()– nodeExited()

• No need for maintaining state

Node 1Node 1

Node 2Node 2

key1 =

value1

key2 =

value2

key3 =

value3

key4 =

value4

Key2_1 =

Value2_1

Key2_2 =

Value2_2

Key2_3 =

Value2_3

Key2_4=

Value2_4

[2] node1.get(key3)

[1] node1.register()

[3] data = node1.fileGet( “filename.doc”);

BonAHA – OO Network Events

TXTRecord

DNSRegistration

RegisterListener

serviceRegistered()

DNSSDService

BrowseListener

serviceFound() serviceLost() DNSSDService

ResolveListener

serviceResolved()

DNSSD.resolve()

DNSSD.register()

TXTRecord Host IP

DNSSD.browse()

set()

Bonjour State Diagram

BService

BListener

serviceUpdated()

set() register() setListener()

serviceExited()

BNode

get() getHostName() getHostAddress()

BonAHAState Diagram

Example: LocationFinder

• Scenario– Two nodes meet each other– Lack global knowledge of location– Each can find out other’s last location

information

Code: LocationFinder

Compare: Bonjour Code

Comparison in numbers

LocationFinder

Lines of Code

BonAHA Code Bonjour Code

Complete class 79 148

Only ad-hoc application functionality

~8 ~60

TicTacToe

• BonAHA sample application

• Shows use in– Multi-player games– Mutual awareness

• Demo

Related Work

• Proem (2001)– Needs to run on “peerlet engine”– No public documentation of API

• JXTA– Excellent for P2P– Heavyweight for our goals

• Peer2Me– Only Bluetooth

Related Work

• LightPeers– Sep 2007 PhD dissertation (B. Christensen)– Similar model to BonAHA

• “Application”: Each application has its own GUID that identifies it

• “Session”: A group of nodes registered as running the application

– Code• Application app = new Application(appid);• lpconn = new Connection(app);• ses = lpconn.CreateSession();• List<Session> sessions = lpconn.GetSessionList();

Related Work - LightPeers

• Differences with BonAHA– PING packet sent every second to

search for peers• In Bonjour, there is exponential backoff

– No library-daemon interface• LP “server” listens to packets

– Reimplementation of entire architecture (service discovery + framework)

Related Work - LightPeers

http://www.daimi.au.dk/~bentor/LightPeers/

Future Work

• Fix some non-OO API features– Allow one BService object to create several

instances.E.g.: one node may want to serve HTTP on two ports.

– Demarcate BService and BNode objects further to reduce discrepancy in working

• Perhaps add high-level communications API for simple networking tasks.E.g.: getFile(), notifyPeer(), sendObject()

Conclusion

• New scenario: highly mobile networks without infrastructure

• Require a new class of application – “ad-hoc” or “mobile P2P” apps

• Require a new framework for programming these applications

• BonAHA, built on top of ZeroConf service discovery: a framework towards building such applications

Questions

• Or Suggestions

Backup Slides

Problem

• Initial version of 7DS (circa 2005)– “Dumb” multicasting to announce and

get information from peers

Solution

• Late 2005 / Early 2006– Looked at writing our own framework for

solving this problem

• But, good news:– Service discovery does exactly this

• ZeroConf: Most widely implemented– Apple’s Bonjour, Avahi, …

Apple’s Bonjour

• Implementation of Zero Configuration Networking (ZeroConf) by Apple Computer– This is what enables sharing in iTunes,

iChat, etc.

• Implemented on Mac OS, Windows, Linux and some other POSIX platforms– Ported to Windows CE as well

Apple’s Bonjour

• Two main components– mDNS Daemon

• Takes care of all Zeroconf events• Listens to network events (link up, down, …)• Listens to mDNS traffic and keeps track of

all service announcements and requests

– Library (Interfaces for C, Java, …)• Allows applications to announce, browse for

and resolve services

Apple’s Bonjour

• Details: Presented in Fall 2006– http://developer.apple.com/networking/b

onjour/

• Important things to remember– IP address autoconfiguration: Link-local

addressing• Pick random from 169.254/16

– Hostname resolution: mDNS• DNS-like protocol, each host listens on

224.0.0.251, port 5353

Apple’s Bonjour

• Service Discovery: DNS-SD– DNS PTR records– Announcement of form:

ServiceName._http._tcp.local.

– Browsing for _http._tcp.local. gives list of web service instances

– Resolving ServiceName yields hostname, TXT records, etc.

TXTRecord

DNSRegistration

RegisterListener

serviceRegistered()

DNSSDService

BrowseListener

serviceFound() serviceLost() DNSSDService

ResolveListener

serviceResolved()

DNSSD.resolve()

DNSSD.register()

TXTRecord Host IP

DNSSD.browse()

set()

Bonjour State Diagram

BService

BListener

serviceUpdated()

set() register() setListener()

serviceExited()

BNode

get() getHostName() getHostAddress()

BonAHAState Diagram