one.world — System Support for Pervasive Applications
Download
Report
Transcript one.world — System Support for Pervasive Applications
Active Everything
Robert Grimm
New York University
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
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 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 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 en systems injecting a large
number of capsules into the network
External inspection to limit intra-network resource
consumption
Pulling Back: Java as Mobile Code
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 approximately 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?
Finally: Course Evaluations
What additional software would you like to have
for your assignments?
Please provide your answer in the “additional
comments” section and prefix it with “more software”