Setup and configuration
LocalProxy is designed to need no configuration 'out of the box'. However
...
If you get a recent version of the right configuration for your environment,
use the GUI to select that configuration, 'start services', configure your
browser/client appropriately (set the proxy/service it uses to localhost:10080
or whatever) and surf/read news/etc.
If there is no appropriate configuration for you, read on.
If you have no idea at all, and there's no provided configuration, or to
get a configuration file as a starting point, try the 'AutoConfigure' button
on the advanced window. Be prepared to wait for the firewall and proxy tests
to complete.
You cannot do much damage to localProxy's operation by adding extra proxies
at each layer (see below), so feel free to experiment. If you put many proxies
in the configuration file, it will just take localProxy longer to learn
which ones are good. Although localProxy is designed to work with many proxies,
some bad, it will always help to start localProxy off with a good configuration.
To do this, you need to understand how commStrats, and proxies configured
are used by localProxy. Hopefully the following will make this clearer.
Services
A client application (maybe your web browser) connects to localProxy and
makes a request. The port it connects to defines the service class (e.g.
http proxy) and type it requires (standard, or anonymous, for example). The
(service specific) commStrat and layer 0 proxy (and, when needed, the layer
1 proxy) for a particular request are all selected at random (preference
to fast ones) from the lists provided in the distributed configuration,
modified by your additional data in the config-<yours>.xml file.
Continuing the web browser request example, each component of a web page
is a separate request as far as localProxy is concerned, so there are many
paths (commStrat/layer 0 host/layer 1 host/) selected for each page for this
service.
CommStrats
These are the strategies used to access the web site requested.
Layer 0
This is a list of hosts (proxies or redirectors usually) which localProxy
will connect to directly.
Layer 1
This is a list of hosts (proxies usually) which will be used only by commStrat
1 (CONNECT via a layer 0 host). The layer 0 proxy is told to CONNECT to
these layer 1 proxies and the browser then requests the web page directly
from the layer 1 host (in the web browser example this is a proxy service;
in other cases, it is most likely the required service directly (e.g. a news
server:port)). See 'distributed' and 'normal' services in 'concepts', for an explanation of this.
When commStrat 1 is in use, the layer 0 host is in a 'pass through' mode.
The currently enabled list of commStrats is:
0. Requests from (and content returned to) your browser are unmodified (except
in some HTTP error cases). This strategy is used with proxies you may be
able to directly access (non-standard, unblocked port proxies, like 8000
for the UAE, or redirectors on an outside account). The proxies are connected
to directly from localProxy (and so must be on unblocked ports). Redirectors
on shell accounts which redirect connections to a blocked public proxy behave
like a proxy, and so may also be used in this commStrat. There is no layer
1 set for this commStrat and the layer 0 proxy will make the request directly
to the web site (redirected by a redirector if that's what the layer 0 host
is).
1. 'CONNECT': The layer 0 proxy is connected to directly and requested to
CONNECT to a layer 1 remote (standard, blocked port) proxy. In this mode,
localProxy's operation is similar to HTTPort (but it will, in addition, 'fail
over' to good proxies and prefer the faster ones).
2. 'Modified url': Similar to commStrat 0, but the URL requested is modified
using various encoding techniques to bypass regexp censoring proxies, such
as those in use in the Middle East. Modifications as simple as changing the
case of a character can easily defeat the censoring in the UAE, for example,
while other, more complex modifications defeat the censoring in the KSA.
Most 'substrategies' of this strategy will not allow uncensored access if
the censoring is based on the web site name - it's usually only good for
the URL path (the stuff after the site name). For example, this commStrat
will get you to my old (blocked) page: http://www.angelfire.com/wy/5waynes/software.html,
because www.angelfire.com is not blocked, but it will take some time to
learn to get you to http://www.sex.com/ because the blocking there is done
on the site address. CommStrat 2 tries various forms of site name and path
modification (32 bit address, hex encoding, octal encoding, Akamai-like
requests etc., CGI proxies (including translation sites etc.)).
3, 4, 5 ... 9 Not implemented yet. 0 through 2 are all that is necessary
for most ME users, but I will listen to requests.
Configuration
Configuration examples are provided for individual ISPs and countries (UAE,
KSA). These should be mostly adequate for UAE and KSA. Other examples are
provided to show how to customize them (User0, wayne-dialup) for different
situations. New configurations for experimentation may be added by simply
copying a config-<config name>.xml files to a new file config-<new
config name>.xml.
User configuration should be done in the config-<configName>.xml files
only.
The other *.xml files are the ones I will distribute with later releases
and contain a basic data set used by all. These are:
- hosts.xml - a list of all the proxies and hosts known and tested. The
tests are done with statProxy and mergeHosts to enable (almost) automated
analysis of the capabilities of a list of proxies through to production
of the updated hosts.xml with updated/new hosts and tags. I can't keep this
list up to date by myself, and, in the true spirit of open-source, welcome
all test results (statProxy output format preferably).
- firewalls.xml - a list of the known firewalls and their firewall rules.
- services.xml - a list of some types (classes) of services and their
properties and requirements. Note that several instances of any particular
service class may be configured and run by localProxy; it's just a matter
of adding them via 'addService', or into the user config (with different
listening ports to avoid conflicts, of course).
- commStrats.xml - the list of available communication strategies, together
with their capabilities and requirements. For example, the specific
capability requirements for things like proxies to use for localProxy's HTTP
proxy service, commStrat 1, layer 0 hosts (which require CONNECT capability)
are specified here. These are used by localProxy when it's selecting hosts
to fill all the service.commStrat layer 0, and 1 appropriately.
At this time, I haven't incorporated a good XML editor, so you need to find
your own. Web browsers do a good job of displaying these files (Internet
Explorer is best), and Mozilla 0.9.5 (or better) is good for editing them.
There are other free XML editors around as well. Most changes to the config
files may even be done with a text editor (my favorite method).
User's proxies may be tested and added into a user configuration to make localProxy
consider them for it's build. This may be done by using statProxy.pl and
mergeHosts like this:
perl statProxy.pl -t all proxy1.emirates.net.ae:8080 > test.out
perl mergeHosts.pl test.out config-wayne-dialup.xml
(use your own proxies and configuration file, of course).
I prefer the command line approach above, but most users will probably prefer
to do this by using the 'test and merge' field and button in the GUI, like
this:
Select the configuration you wish to update
Enter the proxies you have in the appropriately labelled field in the GUI
Click 'Test and merge user proxies'.
Wait ... follow the instructions.
You may need to reselect your configuration at this point, or restart LP and
select it.
Start services
Look at the example, and at the 'wayne',
'last', or 'auto' configurations to see a few of the things which may be done.
In the end, it is possible to overload any of the tags used in the distributed
configuration files. The appropriate technique may be seen by looking in
these files. Please suggest any other tags you might want - it's easy to
add them to a configuration, but it may be more difficult to make the software
do the right thing with them!
Examples of the use of user configured tag use are:
- overload the default name server for your network. This might speed
up the loading of localProxy and use of commStrat 2.
- change the firewall your computer is behind (maybe to one you also
create in this config file - see the way 'auto' config is done)
- change the subnets behind your firewall
- enable/disable a proxy from the hosts.xml file (overload the 'isEnabled'
tag)