11 Output

Every line of the result is in the form of `host:port@PROTOCOLMETHOD estab pcon end req'.A sample of the output:

     222.216.109.55:3128@HTTPC 0.032189 0.126676 0.161449 0.034833 HTTP:GET
     64.34.113.100:80@HTTPC 0.372466 0.367725 1.555638 0.375829 HTTP:GET
     59.41.253.35:80@HTTPC 0.025951 4.463531 0.687924 1.077910 HTTP:GET

By default, proxyknife use the default testmethod, the req field will be filed with `HTTP:GET' now. If you use your own testmethod with `-C msn.req' (see Startup Options) (see Customize Request) on command line or `checkreqin=msn.req' in startup file (see Startup File), this field will be filled with the argument or value, the filename of the request file, which is 'msn.req' in this case.

The current version of proxyknife output timeouts of every steps of validation:

Method	Output (time increase ->)
HTTP_GET	host:port@HTTPG estab 0 pget end req
HTTP_CONNECT	host:port@HTTPC estab pcon get end req
SOCKS5_CONNECT	host:port@SOCKS5C estab pcon get end req
SOCKS4_CONNECT	host:port@SOCKS4C estab pcon get end req

The chart of validating:

Proxyknife -- (myproxy) --- testproxy -- target(checksite) ta ----------------> estab = tb - ta tb <---------------- tc ------------------------------> pcon = td - tc HTTP_CONNECT,SOCKS5_CONNECT or SOCKS4_CONNECT. td <------------------------------ te ------------------------------> (p)get = tf - te get:HTTP_CONNECT,SOCKS5_CONNECT,SOCKS4_CONNECT, pget:HTTP_GET tf <------------------------------ tg ------------------------------> end = th - tg th <------------------------------

The meaning of symbols in the chart:

symbol	meaning
–	start to send, the left string is time.(such as ta)
<-	The data entered,the left string is the time when data come in.
ta tb tc td te tf tg	coordinate time in seconds during a single validating

delay	define
estab	Delay from the time(ta) proxyknife send CONNECT request for testproxy to myproxy(or begin to connect to testproxy directly) to the time(tb) it receives `Connection Established'(or the connection to testproxy is completed).
pcon	Delay from the time(tc) proxyknife send CONNECT request for checksite to testproxy to the time(td) it receives `Connection Established'. With HTTP_GET method, it is impossilbe to get pcon, which is included in pget delay.
get	Delay from the time(te) proxyknife send HTTP GET request for checksite to testproxy to the time(tf) it receives the first byte data returned. Exclusive for HTTP_GET method.
pget	Delay from the time(te) proxyknife send GET request for checksite to testproxy to the time(tf) it receives the first byte data returned.
end	Delay from the time(tg or tf) proxyknife receive the first byte data to the time(th) it receives data including key.

If we define `TP' as `testproxy', `TG' as `checksite', then we got the `approximate mathematics' of the delays:

     estab resp of TP
     pcon  resp of TP + relay of TP + resp of TG
     get   resp of TP + relay of TP + resp of TG + servicestart of TG
     pget  resp of TP + 3/2*relay of TP + 2*resp of TG + servicestart of TG
     end   0.5*resp of TP + 0.5*relay of TP + 0.5*resp of TG + serviceend of TG
     
     total 4.5*resp of TP + 4*relay of TP + 4.5*resp of TG + serviceall of TG
     2*end-get        2*servicedata + service(2*stop-start)
     
     relay: time(data_out) - time(data_in).
     resp: response.
     serviceend = time intervals(send data) + time intervals(stop this task).

A guide to use the result:

• If you want to select a testproxy with the quickest response to you, just sort the result by estab.
• If you need a testproxy through which you can get the quickest response from the single checksite (see Startup Options), please sort by pcon if possible. If include the service response but not connect response only, use get or pget instead. Certainly, you can guess the distribution of route from testproxy to checksite by comparing pcon - estab, etc.
• On the other hand, if you care for the bandwith of the whole route to target, you should sort by 2*end - get. Tt is not accurate if the data returned by checksite is not large enough.

If you still feel puzzled, these tips are for you:

• You can sort testproxies by estab if you want to browse webpages via testproxy (either connect to myproxy firstly or not).

  This is the common choice if you need quick responses to all of the sites in average.

• You can sort result by get or pget if you wantto brower webpages of the checksite (see Startup Options) frequently via testproxy.

  It is a good choice if you care the first response from the checksite (see Startup Options) only.

• You can set mytagconreplysize to a big number, select a suitable checksite(a page with large data), and sort testproxies in the result by end if you want to download files via testproxy(through myproxy firstly or not) from checksite.

  Bandwith but not delay is important to bulk download.

Some of other proxy hunters prefer the total delay. From the approximate mathematics and the chart, I can't get the same conslusion. I think the total delay is not as useful as estab,pcon,pget,get or even end. If you have some different ideas, please send email to bug-proxyknife@gnu.org.

Tips: The less delay, the more speed. You should select the testproxies with the shortest delay, such as estab,pcon,get,pget or end.