Your SlideShare is downloading. ×
talk
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

talk

229
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
229
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Hi, my name is Jing and I’ll be presenting Haggle. Haggle is a systems solution that simplifies mobile networking for applications. This is work I participated in as an intern at Intel Research Cambridge. A significant amount of this project was already underway well before I arrived, and one of the principle architects is James Scott, who is now at Microsoft Research Cambridge.
  • Many other individuals were instrumental in the design and implementation of the architecture. This talk will mostly be at a high level, trying to give the basic flavor and motivation for the Haggle architecture. The main focus of the talk will be on the concept of the architectural design and some of the interesting aspects of what it enables. For many other considerations and details not mentioned in this talk, I encourage you to refer to the paper.
  • * Spell out, they’re mobile I’m going to start this presentation with a running scenario…. a challenge, if you will. The challenge is as follows. Bob and Alice are both mobile users, attending a conference. Bob, who is sitting next to Alice, wants to send her an email thread discussing an attached PowerPoint presentation. So what would the obvious solution be? Well, just use email! But there’s a slight snag, no cellular coverage.
  • Okay so cellular is out. What about a hotspot access point? This also might be unavailable. No coverage, over-congested, or they could be non-open or non-free.
  • Okay so they decide that they both have capable devices so their establish some kind of ad hoc peer to peer link to send the email over. Amazingly, this won’t work either! Even with their devices linked, the email will refuse to be sent.
  • So they give up and use a USB key to transfer the PowerPoint file. While this works in getting the PowerPoint transferred, something really important got lost… we lost the email context around the PowerPoint. It’s no longer an email. How to see the thread of discussion, the participants, email addresses, times of discussions, etc.
  • So why doesn’t email work in ad hoc connections? It’s because Bob’s email client has built-in logic that ties it to the Internet. Specifically, to deliver email, it tries to use DNS to look up the Mail Exchange record for the domain portion of Alice’s mail address. Obviously in ad hoc the DNS is not available.
  • (pause, slow down) The bullet points are a bit sparse and don’t say much to someone if they don’t catch what I’m saying. Spend some more time relating back to the example. Explain the observational points. We observe that mobile networking experience is very poor. Users have to manually configure and manage their devices and applications because application logic is intertwined with the underlying network technology. As a result, applications cannot react to or take advantage of rich mobile environments. But there’s hope. The mobile hardware works. What we need is a systems software solution.
  • The solution is the separate applications from the complexities of underlying networking concerns. Allow applications to focus on their logic and serving the user. Once the networking concerns have been separated, we develop a new node architecture for the mobile device that manages the node’s networking. This new networking architecture tackles the challenges of mobile networking using two techniques: First, late-bind the networking resources based on the devices capabilities, such available battery power and radio types; the networking context; and user preferences such as high/low priority messages and willingness to pay for certain networks. Second, provide integrated resource management so that networking resources are used effectively and in a manner consistent with the user’s preferences. Haggle simplifies the user’s model of mobile device networking. One application for one user level purpose. If the user wants to use email to send a message and attachment, and the network is there, it should just work.
  • What’s in an application from the perspective of mobile networking? An application has Data that it externalizes to some kind of persistent store, but how that bucket of bits is interpreted, the meta-data, is internal to the application logic. Application logic also contains the set of protocols that the application knows how to communicate over, and the type of network interface it can use those protocols over.
  • For an email client the data contains the bits for messages, folders, and attachments, but how to interpret these bits is in the application logic which knows how to interpret this meta-data. The protocols that a mail agent understands would be POP and SMTP, using a TCP/IP socks interface.
  • We need to externalize the network interfaces, such as WiFi or Bluetooth, from the application as well as the protocol that is used over the interface. We also externalize the meta-data to support deep introspection by the network architecture so that the appropriate transformations can be applied depending on the late bound protocol and network interface. For example, to reach an individual, Haggle may need to transform an email to a MMS. You need the meta-data to transform the rich text and attachments.
  • To recap, we’ve separated networking from applications to enable seamless mobile networking. So how do we build a new networking architecture which enables seamless mobile networking? To understand this, we need to understand what are mobile networking environments, and what it means to seamlessly move through them. Haggle considers three main categories of networking environments: infrastructure, ad hoc, and delay tolerant or pocket switched networks.
  • We’ll use an example to illustrate what Haggle means by seamless mobile networking across dynamic mobile environments. Bob starts his week at his office where life is good and Internet and infrastructure is freely available. He then travels to a conference where he has many discussions with colleagues. In these discussions, they want to exchange data and messages, so their devices form ad hoc networks. Infrastructure isn’t available everyone’s device has to cooperate and help forward each others’ packets. Bob then travels to a rural location to study how Ubicomp technologies can help improve health-care. The only means of networking is via a delay tolerant network provided by a postal truck doing daily rounds. Here the device must understand how to operate under long periods of disconnect. In these different networking environments, how endpoints are addressed, the method of transport, and the expectations of the network behavior can vary dramatically. These dramatically different network characteristics is what makes existing apps unable to cope.
  • The Haggle architecture provides a data-centric application API which allows them to work free from network complexities. Instead of a rigid layered architecture, Haggle’s compartmentalized managers handle the late-binding of endpoint names, forwarding algorithms for pushing data, protocols used for encoding data, and interfaces used to communicate over. Next I will talk about how Haggle uses late-binding to determine HOW the networking resources get used. Then I will describe the integrated resource management which determines WHEN the networking resources get used.
  • Need a quick re-cap that we’re going to talk about how late-binding is going to take place. Clarify (more slowly) that we have a rich name graph but here it is a compressed simplified set.
  • Before transition to next slide…. These are paths. Now we will talk about how haggle determines which paths to take and when.
  • Need a re-cap. Late binding shows how to take action. How do we know WHEN to take action. Stop talking from perspective of Task. Just say, actions are delegated. There are things we need to consider: the benefit of the action, and the cost of the action. All requests for action in Haggle are expressed as Tasks. Tasks take into consideration two functions, the benefit of the task as well as its cost. As device and networking conditions change, the benefit and cost functions for the task return different values. The resource manager performs a cost/benefit comparison to decide which actions to allow and when.
  • Reword first bullet: Enable new application features * easy to express optional or async tasks By delegating and late-binding actions, applications can easily express many desired actions, such as a web browser requesting predictive downloads of links and popular bookmarks, high priority operations for pages the user is actively waiting on, or hoarding requests. Unlike traditional applications where too many simultaneous network sockets can overwhelm the system or cause it to use resources poorly, the haggle architecture balances when and how network resources are best used.
  • We implemented support for two legacy applications, messaging via email as well as web browsing. With Haggle enabled web-browsing, you can search for data in the caches of other Haggle peers when the infrastructure is not available. For example, at a conference where the AP is congested, it is likely someone has a cached copy of the conference schedule and proceedings. It’s in the environment, my device should be able to find it. * Maybe break into 2 slides…. Second slide talking about the prototype applications of the prototype arch. Use a picture (figure) to make the apps nice looking and easy to understand.
  • Take some more time (short) mention some interesting aspects about the implementation and explain the behaviour we see. * Must mention… for haggleboth - adhoc/ap is a limitation of how WiFi is used. We can have stuff like multi-net to fix these problems.
  • Emphasize that p2p is giving key new functionality that you otherwise cannot get.
  • Haggle is a stab at a clean-slate redesign of the network architecture for mobile devices. Haggle eases the ability to design applications for mobile network environments by taking the networking out of the application. The result is a cleaner model which allows users to use familiar apps without having to be networking experts. The networking model is: if data could get there or be found there, Haggle enables it.
  • To protect data, we can use existing solutions of cryptography, provided that it doesn’t require synchronous access to some highly available third party. This is because the third party might not be available in all situations. Enabling greater ability to use the rich mobile environment also creates a new threat to privacy, in that it potentially allows you to be tracked. Also, because the name graphs in forwarding objects are richly populated, there can be significant private information in it. There are possible solutions that can help address this, such as forwarding algorithms which are aware of social circles and only forward detailed private information to known contacts.
  • With the Haggle framework applications can very easily make predictive hoarding requests easily according to user preferences instead of worrying about networking code. Applications can now automatically make resource consumption decisions according to user preferences. For example, the user wants their vacation photos uploaded to Flickr, but not via expensive GPRS.
  • To describe the problem, let’s start with a scenario. Suppose Bob wants to send a message to Alice. Though I call it a message here, we can imagine a more concrete and common example, such as an email thread discussing the revisions for a PowerPoint presentation. The obvious choice is to use email to send the message. However, there are some potential snags. There might not be hotspot or cellular coverage available, or the monetary costs to use them at the moment are too high. So what do they do? The current solutions available to day require manual labor. They could reconfigure their devices to connect ad hoc (BT or WiFi) and perform a p2p file transfer, or more commonly, the would use a USB key to transfer the file. But this band-aid solution that we use today is incomplete, because it loses the context of file. In the case of the power-point presentation, the entire thread history is lost. Of course there are many possible work-arounds to attempt to preserve this context, but none of them work universally and require significant user intervention. For regular users Bob and Alice, it’s not obvious why they can’t email each other even after they managed to connect their devices via a BT ad hoc network.
  • Another scenario which exemplifies the shortcomings of the current state of the art is the inability to ask for content from other mobile peers. For example, suppose you were at a conference and you want to look up some local restaurant information, or read today’s news headlines because you were bored. Chances are, this kind of information is available in the caches of the peers around you. Unfortunately, you can’t get at it, even if the peers are willing to share it with you. Even if I wanted to share a cached page with someone else using a USB key to transfer the page, I would have a hard time finding the right cache file and necessary related files to reconstruct the page.
  • The underlying problem is that the current layered networking architecture forces applications to specify many networking details, such as binding endpoints, communication protocols, and network interfaces to use. Designing and building an application which supports dynamic selection and binding is very difficult. As a result, applications are designed to an assumed set of networking conditions and availability of certain services (such as DNS). Because applications are not designed for dynamic mobile environments, managing and coordinating resource usage is hard. Right now, we leave it to the user to decide what apps to run or what operations to perform. The result of having specific applications targeted for specific networking conditions and leaving it to users to choose and toggle between them is that applications internalize all of their data and meta-data context because it was previously not possible to cooperatively use and share this information. This is what leads to the current state of systems, where even if we wanted to cooperate and share in this rich mobile environment, it is very hard.
  • Haggle’s proposed solution is the free applications from networking responsibility. Applications use a data-centric model of focusing on their processing logic, and procuring and disseminating data. We provide a mechanism that makes it easy and natural for applications to expose meta-data and relationships of their data for their own purpose. This same mechanism allows applications to search and procure data easily between applications as well as across applications on different nodes. The haggle node architecture manages the core networking logic, allowing it to make dynamic binding and resource management decisions. The result is that applications are now able to dynamically function across mobile environments seamlessly.
  • Because mobile devices can dynamically transition across many different types of networks, ranging from well connected infrastructure to highly disconnected pocket switched networks, Haggle must support all of these networking modes in its design for handling networking logic. An important aspect of this consideration is the basic problem of Naming. Depending on the networking context, directory services for resolving names may be different or completely unavailable. Furthermore, names which are usable in one network, for example email addresses, have no context in other networks such as bluetooth piconets. To support all of the targeted network types, Haggle must provide a rich naming system. Depending on the network type, forwarding decisions can be dramatically different with different anticipated results. Infrastructure networks can expect near-guaranteed endpoint-to-endpoint reachability without need for cooperation. MANETs can reasonably expect endpoint rechability but requires cooperation. And PSN expects long disconnects using store and forward; and depending on the protocol, cooperation may or may not be necessary. How to forward messages as well as when to perform which actions due to changing power, priority, and cost conditions are decisions no single application can make alone. By externalizing the forwarding mechanisms and resource management decisions, we can potentially run many different forwarding algorithms simultaneously. The resource management system will be able to choose the best forwarding mechanism based on the current context.
  • The result is that applications can focus serving the user, and has a simpler interface for procuring, disseminating, and searching for data regardless of the network.
  • The basic building block of Haggle’s data model is the Data object. Each data object contains an arbitrary number of type/value attribute pairs. These attributes are used for expressing both the data content as well as the meta-data context. Data objects can be linked together using directed edges to express relationships, structural organizations, and ownership.
  • There are several specialized data object types in Haggle, of which I’ll highlight a few. One of the specialized types is a data object filter which is what applications use to search for data. Filters can be made persistent, so that they have a “subscribe” type of behavior instead of a simple one-off.
  • Messages are marked by a special data object called a forwarding object. The forwarding object contains links to the set of data objects which need to be sent, as well as a rich graph of name objects describing the intended recipient.
  • An interesting and powerful specialized data object is the data object filter. These filter objects not only allow us to search for data locally, but also to express subscription requests to other local applications as well as applications on remote nodes. Data object filters consist of a regular expression describing the kinds of data objects to acquire. The filter objects can be one-time or persistent. For example, the data object filter mechanism is how a Haggle-enabled web browser can query for all data objects in nearby nodes which have HTTP content containing the keyword “news”.
  • Forwarding objects are special data objects containing meta-data such as priorities and TTL. The forwarding objects themselves contain links to all related data objects as well as graphs of names for the intended recipient. Because the full structure of the name is sent, intermediary nodes can make the best forwarding decision given their current context.
  • Haggle embeds data object information as a a hidden attachment. If the receiving node is Haggle enabled it will properly unpack and integrate this information. What’s interesting is that we can use the email infrastructure as a store-and-forward medium for more than just simple mail messages. It can be used to communicate all kinds of information automatically transparent to the user.
  • Point out semi-log graph. (only if questioned.)
  • P2P web results perform faster in the complex rotten tomatoes case (over “no haggle”) because the meta-data structure indicated what related objects were needed and shipped all of the data objects together instead of requiring multiple round trips up and down from the browser and into Haggle.
  • Transcript

    • 1. Haggle: Seamless Networking for Mobile Applications Jing Su University of Toronto (interned at Intel Research Cambridge) James Scott Microsoft Research Cambridge (previously Intel Research Cambridge)
    • 2. Haggle: Seamless Networking for Mobile Applications Eben Upton, Meng How Lim (Intel Research Cambridge) Ashvin Goel, Eyal De Lara (U. of Toronto) Jon Crowcroft, Pan Hui (Cambridge University) Christophe Diot (Thomson) In collaboration with others from the EU-funded project
    • 3. Scenario
      • Not available
      • Slow
      • Expensive!
      - cellular?
    • 4. Scenario
      • Not available
      • Congested
      • Non-open
      • Non-free
      Cellular zzz grrrr - hotspot?
    • 5. Scenario Ad hoc P2P Cellular Access Point grrrr ZZZ zzz - Ad hoc?
    • 6. Scenario
      • Email context lost
      Cellular Access Point P2P grrrr zzz ZZZ @*#%&! - Just use USB key
    • 7. Why doesn’t P2P email work?
      • Email clients tied to Internet services
        • Needs DNS to look up MX record
        • “ DNS, who is the mail server for work.com ?”
      • Without Internet, email doesn’t work
      To: [email_address]
    • 8. Observation
      • Mobile networking experience is poor
        • Manual configuration of device and interfaces
        • Different apps for different configs
      • Apps cannot react to or take advantage of rich mobile environments
      • The mobile hardware works
      • Need systems software solution
    • 9. Solution
      • Separate applications from underlying networking concerns
        • Applications focus on their logic
      • New node architecture manages network
        • Late-bind network resources based on capabilities, context, and preferences
        • Provide integrated resource management
    • 10. Approach
      • Separating networking from applications
    • 11. What’s in an App? Application Logic Network Code Protocol(s) Data Metadata
    • 12. What’s in an App? Application Logic Network Code Protocol(s) Data Metadata Email client Mail Files POP/SMTP TCP/IP Messages, attachments, folders, tags, flags, etc
    • 13. Externalize Data and Networking Application Logic Wifi Network Code Email Protocol HTTP Protocol P2P Protocol Bluetooth Network Code Metadata Data Data and Meta-Data Storage Protocols Network Interfaces
    • 14. Support Mobile Networking
      • Separate networking from application to enable seamless mobile networking
      • What are mobile networking environments?
        • Infrastructure
        • Ad hoc
        • Delay Tolerant / Pocket Switched Networks
      • Haggle targets all environments
    • 15. The Mobile Networking User Infrastructure Ad Hoc Network Delay Tolerant Naming: IP, DNS Forwarding: dedicated routers everything is reachable Naming: MAC address, peer discovery Forwarding: ad hoc, cooperative forwarding peers are reachable Naming: MAC, IP, … Forwarding: postal truck routing long disconnects
    • 16. Haggle Architecture
      • Data-centric app API
        • Free from net complexity
      • Seamless mobile networking
        • Late binding
        • Integrated resource management
      Haggle Application Interface Applications (messaging, web, etc) Interface Resource Data Name Protocol Forwarding Net Interfaces (WiFi, BT, GPRS, etc)
    • 17. Haggle Architecture
      • Late Binding
      • Integrated Resource Management
    • 18. Late Binding Send Metadata P2P Protocol SMS Protocol email Protocol Bluetooth Interface WiFi Interface Protocols Interfaces Alice Bluetooth 01:12:E8... alice@ Names
    • 19. Late Binding Receive Bluetooth Interface WiFi Interface P2P Protocol SMS Protocol email Protocol Metadata
    • 20. Haggle Architecture
      • Late Binding
      • Integrated Resource Management
    • 21. Resource Management
      • Actions are delegated to Haggle as a Task
      • Must consider Benefit and Cost of action
        • Can change moment by moment
        • Benefit : e.g. priorities and preferences
        • Cost : e.g. energy, time, money
      • Resource manager does cost/benefit comparison using some utility function
    • 22. Implications of using Tasks
      • Network architecture balances how and when network resources are best used
      • Easily enable new application behavior
        • Optional network tasks
        • Predictive downloads
        • High/Low priority operations
        • Hoarding
    • 23. Implementation Status
      • Implemented in Java J2ME for XP, Linux, Windows Mobile
      • Ported to C# .NET (runs better on Windows Mobile)
      • Code at http:// haggle.cvs.sourceforge.net / ( GPL )
      • Prototype Apps : Messaging, Web
    • 24. Haggle Applications (email) Haggle Haggle
    • 25. Haggle Applications (web) Get News Haggle Haggle cnn.com cnn.com
    • 26. Email Results
    • 27. Web Results
    • 28. Conclusions
      • Haggle is a stab at a clean-slate redesign of the network architecture for mobile nodes
      • Take networking out of the application
      • Seamless mobile experience for user
      • If data could get there or be found there, Haggle enables it
      • One application for one user level task
    • 29. The End!
      • http:// www.haggleproject.org /
      • [email_address]
      • http:// www.cs.toronto.edu/~jingsu /
      • [email_address]
      • http:// research.microsoft.com/~jws /
      • Thanks for listening 
      • Any questions?
    • 30. Extra slides
    • 31. Aside on security etc
      • Security was “left out” for version 1 in this 4-year EU project, but threats were considered
      • Data security can reuse existing solutions of authentication/encryption
      • Some new threats to privacy
        • Neighbourhood visibility means trackability
    • 32. Future Work Ideas: resource-aware media sharing
      • Haggle can do predictive application data store, evict it if “more important” data comes along
        • Keep your photo albums in empty laptop space
        • Keep “public” media in TiVo-like fashion
      • Haggle makes forwarding decisions with knowledge of resource consumption and application priorities
        • Doesn’t ship holiday snaps over GPRS from Australia
      • Haggle can share data with neighbours, facilitating use of free fast local connectivity wherever possible
    • 33. Phase transitions and networks
      • Solid networks: wired, or fixed wireless mesh
        • Long lived end-to-end routes
      • Liquid networks: Mobile Ad-Hoc Networking (MANET)
        • Short lived end-to-gateway routes
      • Gaseous networks: Delay Tolerant Networking (DTN), Pocket Switched Networking (PSN)
        • No routes at all!
        • Opportunistic, store and forward networking
        • One way paths, asymmetry, node mobility carries data
      • Haggle targets all three
        • Data may move across all three to get end-to-end
        • Nodes “change phase” at any time – an integrated solution is needed to handle transitions transparently
    • 34. Problem Scenario: Messaging
      • Bob wants to send a message to Alice
      • Obvious choice: email!
        • No hotspot
        • High cellular costs
      • Current solutions require manual labor
        • Reconfigure ad hoc connectivity
        • Use USB key
      • Current solutions are incomplete. Don’t preserve context
    • 35. Problem Scenario: Searching
      • Want some info while at a conference
        • Local food information
        • Today’s news headlines
      • Cellular or hotspot might be unavailable, congested, or expensive
      • Chances are, others around have info
        • But we can’t get at, let alone share, this data
    • 36. Underlying Problem
      • Applications must specify networking details
        • Bind connection addresses, protocols, interfaces
      • Dynamic binding is hard
        • Apps are designed to assume specific networking modes and availability of specific services.
      • Resource usage coordination hard
        • Leave it to manual user intervention/selection
      • Data context is hidden in app logic
    • 37. Solution
      • Free apps from networking responsibility
        • Focus on processing, procuring, and disseminating data
      • Expose meta-data and relations
        • Search across apps and nodes
      • Node architecture contains network logic
        • Binding decisions, resource management
        • Apps function dynamically in mobile environments
    • 38. Externalize Naming, Routing, and Resource Management
      • Haggle targets all networking types
        • Well connected infrastructure
        • Mobile ad hoc networks
        • Delay tolerant / pocket switched network
      • Naming changes across different networks
      • Underlying forwarding assumptions change
      • Automatically manage device use of communication due to power, priority, and cost.
    • 39. Externalize Data and Networking
      • Application can procure or disseminate data through any combination of protocols and networks
      Application Logic Wifi Network Code Email Protocol HTTP Protocol P2P Protocol Bluetooth Network Code Metadata Data
    • 40. Data Object
      • Basic building block of Haggle
      • Contains a set of type/value attribute pairs
      important tag work tag . . . data pdf file type … … [email_address] from Blah text Rfc822 (email) type
    • 41. Data Object Filters no persist is MP3 and has tag U2 regex Filter object yes persist is HTML and contains news and timestamp > 30 minutes ago regex Filter object
    • 42. Forwarding Objects important tag work tag . . . data pdf file type important Flag Blah text Email message type “ Alice Smith” Name Name object [email_address] Name Name object 00:12:EF:… Name Name object PDA device Name Name object high priority 255 TTL Forwarding object
    • 43. Data Object Filters are Powerful Mechanisms Subscribe (send all photos created by user X to X’s PC) “ Web” Search (find “london restaurants”) Remote Listen (wants to receive incoming data) “ Desktop” Search (find mp3s with artist “U2”) Local Persistent One-Off
    • 44. Forwarding Objects
      • Full structure is sent, empowering intermediary nodes to:
        • Use data as they see fit
        • Use up-to-date state to make best forwarding decision
      Forward Data Data Data Data Name Name Name Name
    • 45. Neighbour Discovery
      • Connectivities have responsibility for neighbour discovery
      • Protocols use neighbours to “mark” NOs “nearby”
      • Resource management controls frequency of neighbour discovery
      Haggle Application Interface Applications (messaging, web, etc) Protocol Resource Data Name Connectivity Forwarding Connectivities (WiFi, BT, GPRS, etc) 1. Set task 2. Execute 5. Insert new names 3: Discovery 4. Neighbour list
    • 46. Sending Data
      • API for send split into three (sets of) calls
      • FO can be sent to many nodes using many protocols
      • Asynchronous
      • Benefits of send change with time and context
      Haggle Application Interface Applications (messaging, web, etc) Protocol Resource Data Name Connectivity Forwarding Connectivities (WiFi, BT, GPRS, etc) 5. Set task “send via X” 6. Execute (when worth it) 1. Insert data 7. Send! 2. Insert names 3. Call “send” 9. Raw data 10. Connect & transmit 8. Get & encode data 4. Decide next hop X
    • 47. Receiving Data
      • Incoming data is still processed using tasks
      • Eventually inserted into Data Manager
      • Apps “listen” by registering interests (DOFilters)
      Haggle Application Interface Applications (messaging, web, etc) Protocol Resource Data Name Connectivity Forwarding Connectivities (WiFi, BT, GPRS, etc) 7. Notify interested apps 6. Insert data objects 8. Mine names 2. Incoming connection 1. Bind to networks 3. Connection 5. Incoming data 4. Query resource use
    • 48. Email App Legacy Support Haggle API Localhost SMTP/POP proxy Native Haggle App From: bob@foo.com To: alice@bar.org ... email ... w/ attach Forwarding Object Data Object Name Object
    • 49. Email App Legacy Support Internet Email client on Haggle Standard email client email email Email client on Haggle email P2P Haggle Data Object Haggle Data Object encapsulated in email
    • 50. Web App Legacy Support Haggle API Localhost HTTP proxy Native Haggle App GET slashdot.org Found? Look for URL in Cache HTTP 1.1 slashdot.org Forwarding Object Data Object Filter Object
    • 51. Web App Legacy Support Internet Web client Web server http Object request Internal object cache http http Haggle Haggle
    • 52. Example msg fwd object message/rfc822 ... email... application/pdf ... pdf document Alice 00:01:23:45:67:89 [email_address] Cell Phone Forwarding
    • 53. Future work idea: Resource-aware media sharing
      • Devices could do a lot of media sharing proactively
        • Predictive content download
        • Auto backup/hoarding of multiple caches of content (e.g. photos, media)
        • Sharing media with friends/family/public
      • But resource management is crucial
        • Contrast laptop in docking station to laptop on plane
        • Proactive tasks can exhaust battery life easily
        • Don’t send holiday snaps over GPRS from Australia
      • Current architecture does not suffice
        • IP stack is difficult to configure with user priorities (e.g. when should smart phone use GPRS and when WiFi?)
        • Opportunistic neighbourhood connectivity unutilised
        • Current file system makes it hard for apps to fill disk with “predictive” content
    • 54. Email Results I don't show “no haggle adhoc”, because it obviously won't work.
    • 55. Web Results I don't show “no haggle P2P”, because it obviously won't work.