1 / 26

Active Everything

Learn how to distribute data and computation using active networking, active caching, active names, and the ANTS system. Discover how Java can serve as a mobile code platform.

pmcgrath
Download Presentation

Active Everything

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. Active Everything Robert Grimm New York University

  2. Remember Your Presentation/Demo? • About 15 minutes per group • A short presentation with at least 3 slides • Application: What does it do? • Implementation: How does it work? • Lessons learned: What did you get out of it? • The demo • This machine, your group’s machine, home machines… • Prepare a web page with the presentation and JAR file • Your code • Email me your slides & source code before class

  3. Active Everything

  4. Active Everything • The problem with Internet protocols and services • Based on exchange of state/data • Hard to deploy state-processing functionality • Ensure incremental deployment and localized benefits • Have access to servers, middle-of-the network nodes • What if instead of exchanging data, we could easily distribute data and computations? • Provide better web caching • Including personalized content, access statistics, ads • Make multicast a reality • Make better performance trade-offs • Example: Whether to compress images at server or proxy

  5. Active Everything (cont.) • Well, by using mobile code, we can distribute computations • Key idea: provide a safe execution platform across devices • Modern virtual machines: TeleScript, Java, Microsoft’s CLR • But, what about protection and resource management? • Let’s look at three active examples • Active Cache • Active Names • Active Networks

  6. Active Cache • Basic idea: Run code in web cache • Validate cached document • Create new document • Require server to be contacted • A new header: CacheApplet • Identifies code associated with document • The contract • Cache invokes cache applet on cache hits • Applet failures always result in contacting the server • Proxy adheres to result of cache applet • Cache applet log returned to server

  7. Active Cache API • fromCache • Main method takes request, IP address and name of client, file descriptors for cached file and new file • is_in_cache, open, close, create, read, write, lseek, send_request_to_server, lock, unlock • Provide file-based I/O • Access other server objects • Create temporary log objects • curtime • Shockingly, returns the current time

  8. Active Cache Security • Proctection • Java’s type safety ensures interfaces are observed • ActiveProxy provides limited API (see previous slide) • java.io, threads, processes are off-limits • Applets can only access resources associated with same server • Resource management • ActiveProxy tracks storage size, disk and network bandwidth • JVM spawning process tracks CPU usage and virtual memory size

  9. Basic idea: Combine name resolution w/service access Namespace programs Resolve hierarchical namesand route/process data Are location-independent Run on resolvers After methods serve as continuations (remember them?) Final namespace program invokes first after methods(which typically routes result back to original requestor) API based on a single method Name, reference to data stream, list of after methods Active Names

  10. Active Names Security • Protection • Builds on Java 2 security (we’ll return to this later on) • Provides additional hooks for namespace programs • Certificate to identify caller • Resource management • None implemented!

  11. Capsule-based Extended IP packet that contains not only data,but also code Processed at active nodes Regular IP-based routing at regular routers Code included by reference Cached at active nodes Fetched on demandfrom previous node Lost code messages orunavailable code resultsin dropped capsules Active NetworksThe ANTS System

  12. ANTS API • Node environment • getAddress, getChannel, findExtension, time • Soft-store • put, get, remove • Routing and logging • routeForNode, deliverToApp, log • Again, as for Active Cache, a minimal API • Just enough to build interesting applications

  13. ANTS Security • Protection • Type safety to protect against runtime corruption • Code fingerprinting to protect against capsule code corruption or spoofing • Hierarchical capsule typing to limit sharing • Resource management • Simple accounting to limit node resources • No protection against en systems injecting a large number of capsules into the network • External inspection to limit intra-network resource consumption

  14. Pulling Back: Java as Mobile Code

  15. Java as a Mobile Code Platform • The great big hype: Write once, run everywhere • A relatively elegant programming language • A single, safe execution platform • The Java virtual machine (JVM) • A large set of standardized platform libraries • The reality: Well, uh, hmm • Protection • Resource management • Debug everywhere • Different operating systems, different classes of devices

  16. Protection • Code signed, thus associated with principals • Policy expresses corresponding permissions • Access checks request permissions • JVM walks current call stack and checks that everyunit of code on stack has requested permissions • Check succeeds if all units of code have permissions • Privileged code can limit depth of stack walk • But, platform library designers decide where to check • E.g., file open, but not file read or write

  17. Resource Management • Java’s resource management: None! • Though, we would like to control • CPU utilization • Memory utilization • Storage capacity, bandwidth • Networking bandwidth

  18. Can We Do Better? • One approach: Add new APIs to Java/JVM • Create your own JVM • Good enough for research prototypes (Utah’s KaffeOS) • But limited impact • Change the JVM specification • A long and arduous process (Java Community Process) • Example: Generics will become part of Java in JDK 1.5after approximately five years!

  19. A More Compatible,More Immediate Alternative • Customize the runtime environment • The enabling hook: Class loaders • Load all code • Arranged in hierarchy • If child does not know how to load a class,it defers to parent • Effectively create different namespaces • The same class loaded by two class loaders is not the same!

  20. What Can We Do in Class Loaders? • Make code inaccessible • Refuse to load platform classes, e.g. java.lang • Replace code • Wrap platform classes with more limiting versions • E.g., collect networking statistics in modified socket class and enforce per-application limits • Rewrite code • Modify code to “do the right thing” • E.g., increment memory counter on every object allocation and decrement memory counter on object deallocation

  21. Debug EverywhereA Case Study • Based on one.world and Sun’s JDK 1.3.1 • Running on Windows 2000 and Linux • Task: Stop reading from socket and then close it • Thread blocked in read() method • The obvious alternatives • Just close socket in another thread • read() throws exception on Linux but socket is not closed • Use periodic timeouts and check termination flag • Windows injects spurious bytes into read-in data(which really confuse Java’s serialization) • We exhausted the socket API. What to do?

  22. Debug EverywhereA Case Study (cont.) • Poison values to the rescue! • Select a special object as a close-socket marker • Write special object to socket • Other machine sends object back and closes socket • Sender receives object and closes socket • What are the limitations of this scheme?

  23. Different Operating Systems • Consider the user interface • Java’s Swing provides different look-and-feels • Java native, Windows, Mac OS, Motif • But the devil is in the detail: Windows vs. Mac OS • Menu bar location • Per-window vs. top of screen • Default menus and menu items • Exit in file menu vs. quit in application menu • Keyboard equivalents • None for exit vs. command-q for quit

  24. Different Classes of Devices • Differences don’t stop at user interface • Consider PDAs, cell phones, smart cards • Differ in CPU speed, memory capacity,networking capabilities, battery life, … • Current state of the art • Specialized JVM editions, based on device profiles • Dedicated platform libraries, including user interface • Not Swing, not AWT

  25. Is Mobile Code the Right Approach?

  26. Finally: Course Evaluations • What additional software would you like to havefor your assignments? • Please provide your answer in the “additional comments” section and prefix it with “more software”

More Related