LocalProxy's purpose in life, and it's point of view:
- The user wants to access a service of some kind on the Internet.
- LocalProxy will present this service on a local port for the user
to connect to.
Terminology: I've called this 'abstracting' a service because
it's rather like interposing a layer of abstraction (like an API) on the
Internet.
Terminology: 'service' - a <host address>:<port>
combination.
- The mechanics of how that (presumably blocked, censored, intermittent,
slow etc.) service is abstracted to a local (unblocked, uncensored, more
reliable and faster) service, is not normally the user's concern. This
document offers descriptions of some of the internals which may be useful
for the 'power' user to know.
Terminology: I have called these possible alternative methods
used internally by localProxy, the commStrats (communication strategies).
Various commStrats may be tried to abstract any particular service. To
design for all the possible strategies, it was necessary to handle two
basically different approaches. One involves a direct (or fixed redirection),
simple connection to the service to be abstracted; the other involves
use of a host (an intelligent agent) which can be instructed to connect
to the service.
Examples of the former types of approaches are:
- using a simple direct connection from localProxy (useful when no blocking
is in place, or to special services via ports which are open, like port
8000 http proxies, or news servers on nonstandard ports). Even obfuscated
URL strategies fall into this category.
- using a connection to a relay/redirector/bouncer to relay the connection
on to the required service (Stone, datapipe, redir..). I didn't think this
rated being called an agent, since it's instructions are not given on-the-fly
and can't be changed once it's running. From the localProxy POV, connecting
to these is the same as connecting directly to the remote service.
Examples of the latter types of approaches are:
- use of CONNECT proxies to connect to the service to be abstracted
- Socks proxies
Another type: firewalls which can be convinced to open a port. This one bears
some more thinking about - it's not completely implemented yet. May become
a new commStrat. In localProxy, I have placed the host and port which localProxy
needs to directly connect to (note - not necessarily the host and port of
the service finally abstracted because of redirection and agents) in a service
and commStrat dependent group called layer 0. Both types of strategies need
these. The two types of strategies usually need different hosts in their
own layer 0. Layer 0 hosts often need to be different for different services.
Simple connections only need layer 0 (in fact, there may only be one service
in layer 0 for these). When an agent is being used, the agent is the layer
0 host, and the service to be abstracted appears in layer 1.
- Distributed services - Some services are more complex. The most
common requirement of localProxy is to provide an abstracted (and uncensored)
HTTP proxy service. This is a service which may be obtained from many hosts
(public, external, non-censoring proxies). For reliability and speed reasons
it is desirable to make use of this fact. For similar reasons, it is desirable
to allow many possible routes to be used to get to the remote service.
Additionally, it is necessary to allow both of the major types of connection
strategies to be used, since they are mostly available to large groups
of users, and provide equally good results, on average. LocalProxy can use
a simple connection and several layer 0 hosts (directly accessible http
proxies, or redirectors to standard port proxies) as well as (a
different commStrat) agent connections with multiple layer 0 and layer
1 hosts. For example, the service to be abstracted may be an uncensored HTTP
proxy service, but this may be provide by multiple commStrat 0 or 2 layer
0 proxies, and by multiple commStrat 1, layer 1 proxies. The commStrat 1,
layer 0 proxies are simply a way of getting to the (usually blocked) target
layer 1 proxies.
- Normal services - In contrast, abstracting a news service is much
simpler. There is probably only one remote service to abstract. Others
are of little use since the user may have needed to log on, or the user
may also (in the same session) be accessing a particular newsgroup which
may not exist on another server. Multiple routes to the remote service
can be used though. In these circumstances, localProxy can use a simple
connection with layer 0 (probably via a redirector, but maybe a news server
on a nonstandard port) only (no layer 1 hosts at all), as well as
(a different commStrat) an agent connection (CONNECT, Socks ...) with the
agents in layer 0, while the news service itself appears in the target
layer 1. As an example of this, in the UAE, localProxy would not be able
to place a port 119 news service in layer 0 (since the port is blocked),
so the news service will always be seen in commStrat 1, layer 1 with agents
in layer 0. Of course, if the user has arranged things appropriately (using
a redirector or bouncer outside the firewall), it may also be seen in commStrat
0, layer 0 on a non-blocked port.
- LocalProxy does not attempt to be like a full proxy for all the
protocols it switches, but to behave like an intelligent packet switch.
For example, it understands only enough HTTP protocol to allow it to detect
'access denied' events (to report statistics to the user and to demote use
of that proxy) and such things. It understands no ssh (not that that would
help at all), and no Usenet News protocol etc. Because of this, it needs
a lot of generic and specific information in the configuration files covering
the services to be abstracted. See configuration
and the various xml files in the distribution for the details of each
item of data (I will write DTDs sometime in the future!). As usual with
localProxy, very little of the data is essential but the more you can provide,
the better localProxy will perform.
- LocalProxy has a sophisticated learning mechanism which (inevitably)
involves experimentation with paths it hasn't already tried. This means connection
failures will occur all the time. LP eventually learns to avoid such paths,
but must still continue to try them occasionally. This 'experimental' attitude
can be adjusted by the user from the GUI by means of the 'freeze' sliders
for each commStrat and layer. High values 'freeze' LP and avoid experimenting,
while low values allow LP to freely experiment. default value is 2.
- The CommStrats used:
CommStrat 0: Direct connection to the service to be abstracted
CommStrat 1: Use of an agent (only CONNECT proxies are implemented so far)
CommStrat 2: Any kind of URL obfuscation (includes changing address to IP
address, escaping URL, toggling the case of URL characters, use of CGI proxies,
use of translation services etc.)
- I can't think of any more - remind me.
-wayne