Back to index
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
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
- 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.
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.
- 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