A Proxy-Based Filtering Mechanism for the Mobile Environment
Bruce Zenel, Columbia CS
One-line abstract: App-level and socket-level distinct proxies running
on a server that does much muckage with IP bindings to provide backward
compat and/or impersonate the client. App-level filters ("applets")
are sent from MH to proxy and executed there.
Main points:
- Two simultaneous proxies: low-level for doing network protocol level
optimizations (ICMP echo, etc); high-level for app-specific filtering.
- High-level proxy runs filters that are downloaded from the MH.
- Filters at proxy server become the client by mucking with IP
bindings! (client starts out e2e at MH) HLPS API's in C, at socket level;
for filters written in C, Java,... Applet fork and attach done w/Mach primitives.
- Network-level filter agent sets up reusable paths from MH to proxy,
by mucking with network-level stuff.
Flaws/comments:
- Bending over backwards to preserve compatibility w/existing apps and
high-level protocols (eg "proxied SMTP"), even while doing some
hacks that effectively establish session state. Maybe better to define a
session layer and be done with it?
- No adaptation; no general architecture for app level framing of data
in the HLPS.
- Philosophical difference: we provide app compatibility by proxying the
server-side connection. His requires apps to be relinked with sock lib (or
runtime linking); we can support off-the-shelf Netscape & Eudora.
- In general, these API's are at a much lower level than ours.
Back to index