Back to index
M-RPC: Remote Procedure Call Service for Mobile Clients
Ajay Bakre and B.R. Badrinath, Rutgers U.
Indirect (like I-TCP) RPC, with reliable UDP for wireless part.
Automatic rebinding of services to servers after handoff is done under
the assumption that certain RPC's are idempotent. Lots of
hoopla about how the transport/service layer should
support disconnection and data filtering rather than forcing every app
to handle it
explicitly, but in the end, their implementation falls back on
Overview/Main Points (Reviewer's opinion in italics)
- flexible transport layer: different
clients/services have different needs, and TCP is problematic on
wireless links. (Not clear if this is still true given TCP-snoop.)
- call retries from MSR, to hide from client.
- some support for disconnected operation, e.g. if MH is
temporarily disconnected, client RPC should wait for reconnect
before retrying call.
- automatic rebinding of services after a move.
- backward compatibility, i.e. can talk to existing RPC servers.
- Low-bandwidth data filters, etc. should be supported in transport
layer, rather than forcing each app to do it. I think this
violates e2e (end-to-end) argument and is not a good idea.
Authors say that the above reqts. apply particularly to sophisticated
apps that engage in long-lived conversations with RPC servers; simpler
apps have looser requirements. IMHO, all the more reason to do it
- Client/MSR transport is RDP, to avoid forcing client to deal
w/wireless losses at app level.
- MSR/server is UDP, for compatibility w/existing servers. MSR
looks like a regular RPC client to the server. A problem for
schemes that use client netmask or other form of client
- Clients should bind to services, not servers. Service bindings can be
changed by new MSR after a handoff. Clients can also bind to
servers for compatibility, or non-idempotent calls (see below).
- Assumption: any call made by binding to a service is
idempotent. Ensures that it's OK for new MSR to switch service
to a new server if it wants.
- Disconnection: client can setup app-specific callback that is
called when disconnection occurs, or when RPC fails due to
disconnection. So it's e2e after all.
- Performance: about 4x slower than Sun UDP RPC when no wireless
losses. As lossage increases, UDP performance is dominated by
retry timeout whereas M-RPC performance is "protected" since RDP
is used. Not really big news
Obvious; is to RPC as I-TCP is to TCP, i.e. a mobile oriented solution,
but not really a very good one.
- No mention of how to handle failure semantics with this "split"
model. Who assumes responsibility?
- Much ado about supporting disconnectedness and data filtering in
transport layer, but current impl. pushes this to application
anyway and there is no story for how it might be moved to
- 4x perf hit is about what you'd expect from the added
roundtrips. No discussion of alternate approaches, but authors'
starting assumption is that TCP is bad for wireless. Seems like
RPC over TCP-snoop might be OK, if connection is long lived,
since it also preserves e2e RPC failure semantics.
Back to index