Transcript one.world — System Support for Pervasive Applications

Active Everything
Robert Grimm
New York University
Your Project Statistics at Work:
Programmer Effort
 Minimum
2.8 hours
 Average
9.6 hours
 Maximum
23.7 hours
Effort/person/week
25.0
Hours
20.0
15.0
10.0
5.0
0.0
1
2
3
4
5
6
7
8
9
10
11
12
13
Remember Your
Presentation/Demo?
 About 20 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
Active Everything
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
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
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
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
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
Active Names
 Basic idea: Combine name resolution w/service access
 Namespace programs
 Resolve hierarchical names
and route/process data
 Are location-independent
 Run on resolvers
 After methods serve as continuations (remember them?)
 Final namespace program invokes first after method
(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 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!
Active Networks
The ANTS System
 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 demand
from previous node
 Lost code messages or
unavailable code results
in dropped capsules
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
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 end systems injecting a large
number of capsules into the network
 External inspection to limit intra-network resource
consumption
Pulling Back:
Java as a Mobile Code Platform
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
Protection
 Code signed, thus associated with principals
 Policy expresses corresponding permissions
 Access checks request permissions
 JVM walks current call stack and checks that every
unit 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
Resource Management
 Java’s resource management: None!
 Though, we would like to control




CPU utilization
Memory utilization
Storage capacity, bandwidth
Networking bandwidth
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.5
after at least five years!
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!
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
Debug Everywhere
A 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?
Debug Everywhere
A 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?
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
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
Is Mobile Code the Right
Approach?