ROVER: A Toolkit for Mobile Information Access

Anthony D. Joseph, Alan F. deLespinasse, Joshua A. Tauber, David K. Gifford, and M. Frans Kaashoek, MIT LCS

One-line summary:

Overview/Main Points

Standardized abstraction using relocatable objects and queued RPC to support client-server mobile computing that operates in a weakly-connected or sporadically-connected environment. Think of RPC in which email is the transport.

Relocatable dynamic objects: objects can migrate between client and server, and are lazily fetched from server into object cache when needed. Objects encapsulate data and a standard set of methods that can be invoked, including get, update, flush, set attributes (uncacheable, always verify, expiration, etc.) and various queries.
Other interesting uses for RDO's: exporting computation to server; sending data rendering/decompression code along with the data (like TSM's), modulo binary compatibility.
Queued RPC: Invocations on objects are RPC's. If the object is not present, the RPC is queued. When connection to server is made, queue is drained.
QRPC's are kept in stable log on client. If disconnection occurs while server is fetching object for client, request is replayed when reconnection occurs.
Consistency conflicts are detected by Rover, but resolution is punted to the application. Application can either handle it internally or punt to user. Degree of consistency desired is specified by application to Rover.
A couple of apps (mail, web, ical) were retrofitted to use Rover; required changes to ~15% of code.
Implementation: client side uses IPC to talk to Rover clients; server side can be either standalone or cgi-bin. Network scheduler can send messages using either HTTP or SMTP.

Relevance

Uniform mechanism for accessing and updating data to which mobile access is desired. Main value is probably not in retrofitting existing apps but in designing "mobile from the ground up" apps.

Flaws

No bandwidth management.
No notion of adapting intelligently to changing networks; in fact one of the "future work" issues is deciding when/whether to activate an available NI to drain the RPC queue.
"Our implementation emphasizes modularity over performance": most prototypes do, but if they actually say this up front, does it mean their performance is spectacularly bad, and if so is it because it's a prototype or is it inherent in the architecture?

Back to index