1 / 9

The Problem: Inefficient Protocols

Investigating solutions to make application-level protocols less sensitive to low bandwidth and high latencies, and developing an infrastructure to support these solutions. Explore the inefficiencies of current protocols and propose a generalized meta-protocol with XML structured data access and a mobile scripting language. Improve performance through code and data migration, cache validation, optimization, and adaptation. Measure and analyze latencies of different protocols, design flexible proxies for code and data migration, and model protocol implementations on the proposed infrastructure.

marions
Download Presentation

The Problem: Inefficient Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Proposal: A General Infrastructure for Efficient Application-Level ProtocolsSteven Czerwinskiczerwin@cs.berkeley.edu Goal: To investigate ways to make application-level protocols less sensitive to low bandwidth and high latencies and to create an infrastructure to support the solution.

  2. The Problem: Inefficient Protocols Protocol standardization leads to inefficiencies Compromise leads to “no one wins” situations Different situations have different bandwidth needs But protocols are often developed with only a few settings RTT sensitivity arises from mismatch of client’s needs Multiple protocol commands issued to perform a client action Client must check result of each command before issuing next Standardization favors text-based protocols But text-based are not bandwidth efficient IMAP Operation Times across Different Connections 2 ms latency 70 ms latency Mailbox Sync 44 ms 320 ms Message Move 22 ms 160 ms 6 ms 75 ms Message Fetch

  3. Common solutions Code migration Examples: SQL, postscript, etc.. Pro: Solves mismatch problem Con: Usually tied to particular language Data migration Examples: web caching Pro: Reduces RTT to “server” Con: Incremental solution Home Server Mobile code (high latency) Client Home Server Cache Agent Client

  4. Proposed System Generalized meta-protocol Support access to XML structured data Higher-level protocols layered on top Infrastructure to support data and code migration Data access is done via a mobile scripting language Trusted access servers scattered throughout network Code is passed by reference Scripting language allows for complex behavior Create cache validation and tentative commits as fundamental operations Introspection of code allows for optimization

  5. Architecture Code Server Home Server User State (Permanent Homeof user’s data) Local Access Server CodeURL=netscape-imap-4.2init czerwin password Authenticate czerwin passwordforeach folder x in (Match <folder>yes</folder> <user>czerwin</user>) send tags x <foldername> <foldersize><unread> Login accepted, (INBOX, 25, 5), (Ninja, 20, 0) ... Client

  6. Access language environment Functional based for lowest common denominator Client functions receive parameters, return results Control structures and looping included XML manipulation operations built into language Cache validation operations Operations to hash sets of data for comparing states Query operations only return deltas when possible Tentative commit & conflict resolution operations Allow tentative commits to form branches Support shared libraries, negotiated at handshake Performance enhancing code (such as compression) can be optionally linked in

  7. Adaptability and Optimization Opportunities for adaptability Trade off between code migration and data migration Avoid data migration when bandwidth to client is small Aggressively migrate code when client is computationally poor Initial requests sent to remote server until data migrated Optimization High-level data access commands allow for optimization Profiling of data access patterns allows for pre-fetching and optimistic concurrency Allow for application level hints for optimization Common client libraries preloaded into servers

  8. Alternative: Data structure library Access remote state via data structure library Data structures hide cache, connectivity, commit issues Protocols built on top of data structures Pros Easier protocol development Data always in binary form Cons Library language dependent No code migration Client Device Client App (Data structure Library) Associate Array Local Access Server Home Server

  9. Where to begin? Measure and trace current protocols Detailed analysis of all the latencies involved Benchmark different clients use of the same protocol Possible protocols: IMAP, LDAP, HTTP (suggestions?) Solve problem for one protocol Build flexible proxies that mimic code migration and perform data migration Design access language Is it possible to design with a small set of operations? Model protocol implementations on infrastructure Use collected traces to determine actual performance

More Related