The localProxy back end log window
The localProxy back end log window starts when you click the GUI 'start
services' button.You will see the following types of information displayed
as you browse:
Error messages
These are not (I hope!) localProxy errors. They should be errors localProxy
has encountered when accessing the various proxies and redirectors in your
configuration. They may also be 'access denied' errors. In these cases, localProxy
makes an attempt to cause your browser to refresh, or to redirect your request
to a good path. This cannot always be successful. The request is often lost before the error
occurs, and the user notices a missing advertisement, or image on his displayed
page. In all of these cases you should eventually fix your configuration
to replace these bad proxies or redirectors with good ones. In the meantime,
you can usually just refresh the page to make localProxy choose a different
path and it will avoid using the bad proxies for the remainder of the session.
See browser tips to get the best
out of your browser in this respect.
Speed messages
These are one line messages (one for each network socket closing) which
have the format: s.i.j.k: r0:s0 (s1(p1.q1) s2(p2.q2)...) (s3 s4...) (s5 s6...)
s7(=s8/s9) where:
- s is the service (like 10080, 10119...)
- i is the commStrat (starts at 0)
- j is the index of the layer 0 host in use (starts at 0). The index
is the number of your host in the configuration window for this layer in
the GUI (after 'show config'). The hosts are also displayed in this order
when the back end starts.
- k is the index of the layer 1 host in use ('-' if layer 1 was not
in use).
- r0 and s0 are your averaged, overall real and effective browsing speeds.
The average is a moving
average (previous socket results are given an exponentially decaying weight
as they get older). The decay time is set to cause the average to show an
average over roughly the last hundred sockets. There is often one socket
used for each request, but browsers using HTTP pipelining and the CONNECT
and keep-alive sockets may handle more requests.
- s1, s2, ... are the service.commStrat effective speeds (averaged as above, over
roughly the last twenty sockets).
where p1, p2 ... are the abbreviated service number (service number
- 10000), and q1, q2, ... are the commStrats.
For example: 3.2(80.1) indicates that the HTTP proxy service (10080), commStrat
1 speed is averaging around 3.2KB/sec.
- s3, s4, ... are the layer 0 host speeds (averaged over roughly the
last 10 sockets which used each hosts)
- s5, s6, ... are the layer 1 host speeds (averaged as for layer 0).
- s7 is the socket speed for the socket which generated the log line
when it closed.
- s8 is the amount of data (KB) this particular socket received
- s9 is the 'on-time' within which this socket received that data, so
s7=s8/s9.
These are hard to interpret in general, and it may be easier to use the
graphics available from the GUI.
Sockets may be open, but not in use, so the speed must be calculated
only after a request is made - hence the 'on-time'.
Several considerations make this log hard to interpret:
a) The sockets are all 'keep-alive' sockets, so many browser requests
may be satisfied through just one socket, and only one line will be seen,
maybe a long time after the socket was created. The speeds which determine
the selection of commStrat, and layer 0/1 hosts are those which are present
at the time the socket is created. Things may have changed substantially between
the creation and closure, so there may be unusual numbers of sockets closing
with an unlikely commStrat or layer 0/1 host speed.
b) CONNECT sockets will close anyway, after some random time. LocalProxy
keeps a 'pool' of open ones ready (if enabled). These will periodically
close and display their statistics. The size of this pool is dynamically
determined, and will be low if you have not been browsing, or if commStrat
1 has a low speed, but will be higher if you have just finished some browsing.
All of these (maybe unused) pool sockets will display a line in the log
when they close.
c) If normalization is 'on' (it is on by default), the speeds may be periodically
adjusted. In this case, the adjustment happens to all of the hosts (or commStrats)
in one layer only (the set of numbers in one set of brackets in the log
line above). The algorithm ensures that the speeds are within some sensible
range. Zero speeds are left alone, the maximum speed is left alone, but
the ones in between are rescaled to ensure that the lowest of them is within
a 'selectable with reasonable likelihood' range by the stochastic selection
mechanism of localProxy2. At the moment (likely to be tweaked in future),
normalization is triggered if the range is over one order of magnitude
(10:1) and the rescaling brings this back to one order (10:1).
d) Fast websites, fast streaming content (audio, video) will cause the
path in use at the time to be rated at a high speed. These speeds will
not be representative of your normal browsing speeds. After a bit of browsing
they will return to normal.
e) Some sockets will be seen to be closing with s8=0 and s9=.0005. These
are pathological, and hard to handle in the code.
You may enter only two commands in to this window. Both are unnecessary
(they are done by the GUI) in normal use. They are: ctrl-c to shut localProxy2
down (useful when the GUI has lost contact with the running localProxy back
end for some reason) and ctrl-break (to toggle debug mode). Ctrl-break will
also shut down the GUI if it started this instance of the back end. Some
advanced users may *want* this effect.
An example log and the corresponding analysis
> To:
> From: "Medo Abbas"
> Subject: [Proxy Elites] Re: localProxy troubleshooting
>
> hi, Wayne
Hi, and thanks for this log.
> Merry christmas and happy new year.
Heh, gotta admire a guy who says 'merry' in these politically
correct times :-)
> I have downloaded the new localproxy.zip dated 12-01-01
> I could not browse anything with it, also the older version is no longer
> working.
> Here is the the log of the debuger using level 4.
Executive summary:
1) get a new hosts.zip and drop it into the lp directory.
It will automatically open it up and make a new hosts.xml.
I could give you special, working proxies, but this is a
better way to get them.
2) get the latest software too, at least localProxy.pl, localProxy2.pl,
WLib.pm. Get statProxy.pl if you want to do the tests I ask for below.
3) it appears that your ISP has changed a lot of the proxies we had
for them. You (or someone) must get (and test) the new lot.
> 213.230.0.20:80, used in 10080.1.1, 10076.0.2, 10076.1.1, is not responding
> connectSocket: 204.66.28.229, 7475, 4, 6
Here's the first problem/question for you.
This proxy is definitely inside your firewall, and so port 80 is accessible.
Can you verify that this proxy is alive?
LocalProxy uses the hosts.xml database at build time to set up your
running configuration. That database shows this proxy to be alive.
I can't test it from outside (it's filtered, or it is dead), so you
need to test yourself.
This would not stop localProxy from working though, so we need to
look further.
> 204.66.28.229:7475, used in 10080.0.2, 10080.2.1, 10076.2.1, 10077.1.3, is
> not r
> esponding
This is correct. Your hosts.xml is out of date.
Again, this would not stop localProxy from working.
> connectSocket: 66.91.93.178, 5477, 4, 6
> 66.91.93.178:5477, used in 10080.0.3, 10080.2.2, 10076.2.2, 10077.1.4, is
> not re
> sponding
Same for this one. These non-standard port proxies were only lasting
a few days at most.
> connectSocket: 146.101.66.171, 9081, 4, 6
> 146.101.66.171:9081, used in 10119.1.1, 10080.1.4, 10076.1.4, 10077.0.0,
> 10077.2
> .0, is not responding
This one is alive, but lately has been down most of the time.
The result here was probably correct again.
Bad luck.
> connectSocket: 207.101.80.74, 9081, 4, 6
> I'm assuming your IP address is 213.230.4.102
> online
> 10080.1.0.-: error connecting to 216.20.10.38:8616:
This one is alive right now. 8616 should be open for you, so I
can't explain this except to suggest that it was down at the
time you did your test.
> Created an outside socket for 10080: IO::Socket::INET=GLOB(0x201b2fc)
This proves that some of the proxies LP is using are actually accessible.
> Init connectTime for IO::Socket::INET=GLOB(0x201b2fc) to 1009445922.575
> Original request: GET
> http://us.update.companion.yahoo.com/slv/v4/1.html?v=4.0.2
> .1&t=11239892&.pc=none&.ta=cgnone,ccy!msgr,cius HTTP/1.0
> Using nameservers (timeout: 5):
> 213.230.0.10206.241.58.240213.230.0.20213.230.0.
> 21
> resolved us.update.companion.yahoo.com to 216.115.106.218
> Modified request: GET
> http://216.115.106.218/slv/v4/1.html?v=4.0.2.1&t=11239892&
> .pc=none&.ta=cgnone,ccy!msgr,cius HTTP/1.0
> Average occupancy: 0.14
> Queued an external socket creation for service class httpProxy
> Running online check ... connectSocket: 24.201.75.133, 8141, 4, 6
> 24.201.75.133:8141, used in 10080.0.4, 10080.2.3, 10076.2.3, is not
> responding
Dead now. Your hosts.xml is old. LocalProxy can work around most
of these failures, but if *everything* is failing, you're stuffed :-)
> connectSocket: 205.133.156.4, 7070, 4, 6
> 205.133.156.4:7070, used in 10080.1.3, 10076.1.3, is not responding
Problem here.
This one is mostly alive, and should be accessible to you.
Check manually.
Do this in a command window (when you're connected to the Internet!)
and tell me what you see:
telnet login.icq.com 7070
A few garbage characters means that port 7070 is open.
I'd appreciate it if you do this test for all of the ports firewalls.xml
says are blocked/open there. They are listed under the medunet
'blockedTCPPorts' and 'openTCPPorts' tags.
> connectSocket: 213.230.0.20, 80, 4, 6
> 213.230.0.20:80, used in 10080.1.1, 10076.0.2, 10076.1.1, is not responding
This should be responding to you - I guess it's down. Your ISP must
have replacement proxies periodically. I need to get them tested and the
hosts data updated once in a while. You up to it?
perl statProxy.pl -t all 213.230.0.20:80
should do it properly. Same for all the other ISP proxies.
> connectSocket: 204.66.28.229, 7475, 4, 6
> 204.66.28.229:7475, used in 10080.0.2, 10080.2.1, 10076.2.1, 10077.1.3, is
> not r
> esponding
> connectSocket: 66.91.93.178, 5477, 4, 6
> 66.91.93.178:5477, used in 10080.0.3, 10080.2.2, 10076.2.2, 10077.1.4, is
> not re
> sponding
> connectSocket: 146.101.66.171, 9081, 4, 6
> 146.101.66.171:9081, used in 10119.1.1, 10080.1.4, 10076.1.4, 10077.0.0,
> 10077.2
> .0, is not responding
> connectSocket: 207.101.80.74, 9081, 4, 6
> I'm assuming your IP address is 213.230.4.102
> online
> 10080.1.2.-: error connecting to 213.230.0.21:80:
Ohhh ... another ISP proxy not working.
There are only a few there. There *must* be replacements for these
dead ones. You need to find out what they are.
In many places, the proxies are found by resolving an address like
proxy.medu.net.sa. Your ISP should give you a string like that to
put in your web browser to set up the proxies properly.
Please find that string and do this in a command window:
Win NT/2000:
nslookup string
Other Windows:
ping string (and repeat this until you see no new IP addresses appearing).
Repeat the above on several different days to make sure you get them all.
Then test using statProxy as I showed above.
Post the results to me for inclusion in hosts.xml please.
[... snipped many attempts by LP to use bad proxies;
all good LP learning experiences though :-) ...]
> Created an outside socket for 10080: IO::Socket::INET=GLOB(0x1e46fdc)
You've got at least one working proxy for LP to use :-)
That should be enough, if it has the right characteristics (CONNECT
capable, or vulnerable to commStrat 2 attacks).
> Init connectTime for IO::Socket::INET=GLOB(0x1e46fdc) to 1009446110.706
> Original request: GET http://www.msn.com/ HTTP/1.0
> Using nameservers (timeout: 5):
> 213.230.0.10206.241.58.240213.230.0.20213.230.0.
> 21
> resolved www.msn.com to 207.68.173.253
> Modified request: GET http://207.68.173.253/ HTTP/1.0
Using a simple commStrat 2, type a, URL obfuscation
(www.msn.com -> 207.68.173.253).
> Shut IO::Socket::INET=GLOB(0x201b2a8) down
> Shut IO::Socket::INET=GLOB(0x201b23c) down
> 10080.2.0.-: 0 (-1(76.0) -1(76.1) -1(76.2) -1(77.0) -1(77.1) -1(77.2)
> 0(80.0) -1
> (80.1) 0(80.2) -1(119.1)) (0 0 0 0 0) 0(=0/0.0005)
That '(=0/0.0005)' indicates that this socket closed after getting 0
bytes of data. Not good - it means that either you clicked
'stop' or 'refresh/reload' etc. in the web browser, or the proxy
just shut down. If the proxy, then it's no good anyway.
> Shut IO::Socket::INET=GLOB(0x201b2fc) down
> 10080.0.1.-: 0 (-1(76.0) -1(76.1) -1(76.2) -1(77.0) -1(77.1) -1(77.2)
> 0(80.0) -1
> (80.1) 0(80.2) -1(119.1)) (0 0 0 0 0) 0(=0/0.0005)
> Shut IO::Socket::INET=GLOB(0x1fe1704) down
> Average occupancy: 0.041
> Shut IO::Socket::INET=GLOB(0x1fe1794) down
> 10080.2.0.-: 0 (-1(76.0) -1(76.1) -1(76.2) -1(77.0) -1(77.1) -1(77.2)
> 0(80.0) -1
> (80.1) 0(80.2) -1(119.1)) (0 0 0 0 0) 0(=0/0.0005)
> Shut IO::Socket::INET=GLOB(0x1e46fdc) down
> Queued an external socket creation for service class httpProxy
> Running online check ... connectSocket: 24.201.75.133, 8141, 4, 6
[... more learning attempts ...]
It looks like you just have nothing that LP can use.
It's built a config with 5 proxies in each layer for each service,
based on it's best information (from hosts.xml) at the time.
Then it tries all of these until it finds the working/fastest ones.
In your case, it appears that none were usable using any of the
commStrats available.