Haggle Architecture and Reference Implementation Uppsala, September Erik Nordström, Christian Rohner

Haggle Scenario The scenario (you all know this): – People carry information with them – Ad hoc/opportunistic interactions – Heterogeneous connectivity Architectural problems: – How to agree on names and addresses? – How to exchange information (protocols, tech.)? – How to prioritize the information to exchange?

A Search-based Network Architecture Make searching a first class networking primitive What does searching imply? – Unstructured (meta)data – Query - Keywords/interests – Ranked results How can searching help us in a Haggle-style networking context?

“Searching” in Haggle INFANT INS-inspired namespace – Structured metadata – Hierarchical (name graph/tree) Used to map from higher level name to lower level protocol/interface – Static, and pre-defined mappings No searching – just lookup / tree traversal How map data to user? – Implies destination oriented communication RootServiceCameraResolution640x480Data-typePictureAccessibilityPublicCityWashingtonBuilding White house INS

Searching on the Desktop and the Web Consistent namespaces – Semantic filesystem (Gifford et al. 1991) File attributes along file names User explicitly adds metadata – Metadata extraction and indexing Content-based search – Probabilistic models map metadata (term freq., language models) to search terms Context enhanced search using graph models – Google’s PageRank – Connections (Soule et al. 2005)

Haggle Scenario (contd.) Interests Search for matching content

Searching in Haggle Use searching to resolve mappings between data and receivers

Christian Tryffel Christian Tryffel Christian Tryffel Christian Tryffel Christian Tryffel Christian Tryffel Christian Tryffel Christian Tryffel Christian Tryffel Christian Tryffel Christian Tryffel Christian Tryffel Christian Tryffel Christian Tryffel Christian Tryffel Christian Tryffel

Relation Graph Each Haggle node maintains a relation graph Vertices are data objects Edges are relations = two data objects share an attribute We define our primitives on the relation graph Shares similarities with (local) search – E.g., Connections [Soules et. al 2006], Apple Spotlight, Google Desktop

Filter Demux = filtering associated with an actor Data object Attribute Induced subgraph

Query – Weighting the graph There may be many ways to do the weighting!

Resolve = Cut in Relation Graph Ranked result = {v 1,v 2 } || {v 2,v 1 }

Flexible Primitives Primitives exist and what they are We do Not define how exactly how they operate Different weighting algorithms

Exchanging Data Objects Resolve data/content Resolve node Since content and nodes are both data objects, these two operations are (more ore less) the same

Search Benefits Flexible naming and addressing Late binding resolutions Late binding demultiplexing Content dissemination and forwarding – Deciding delegate forwarders – Ordered forwarding Resource and congestion control – Limit queries – only get best matching content

Query Time

Weighting

Conclusions Search primitives are useful abstractions for DTN-style networking Novel naming and addressing Ranking useful for dissemination – Resource/congestion control – Ordered forwarding (priorities) Better understanding of scaling needed – Query time – Effect on battery life?