Print

[snarked]

Either for the HE app and/or for the tunnel-broker web site:

It would be nice for a person to be able to ping the "nearby" tunnel endpoints (as an automated tool) in order to determine which endpoint(s) appear to be the nearest.  Due to the way network peering with other ISPs is done, the geographically nearest endpoint may not be the nearest in network latency terms.  Existing tunnel-broker clients could use this to compare their current tunnels to that of alternatives, especially when new endpoints are enabled.

By "nearby", I would suggest limiting a given ping to those endpoints on a given continent.  Users in North America and Europe, having multiple endpoints (10+ each), would benefit the most.

For example, someone in Las Vegas, NV (USA) would expect Los Angeles, Denver, or Phoenix to be the closest, but if his ISP doesn't peer with HE in the western U.S., the closest may be an east-coast tunnel server.  Such a person would use the proposed tool to ping ALL North American sites and get the latency results.

Of course, users should still manually choose their tunnel endpoints.  Adding such a tool will enable such users to make a more informed decision.

PS:  I am aware that the "looking glass" can ping, but it is limited to 3 sites, and furthermore, it lists HE's router sites, not necessarily the tunnel-broker endpoints.

[xiecong520]

Support the building Lord. Good idea..
A good example. For example, I am a Chinese user. Ipv6 deployment is relatively backward.
Connect to Hong Kong will want to route to the United States. Delay doubled.

The United States:
PS C:\Users\xxxx> tracert -d 66.220.18.42
通过最多 30 个跃点跟踪到 66.220.18.42 的路由
  1    <1 毫秒   <1 毫秒   <1 毫秒 192.168.100.1
  2     1 ms     1 ms     1 ms  119.xxx.xxx.1
  3     3 ms     3 ms     3 ms  58.51.97.33
  4     7 ms     *        4 ms  58.51.97.21
  5    17 ms    19 ms     *     202.97.67.1
  6    22 ms    25 ms    24 ms  202.97.33.106
  7     *       21 ms    24 ms  202.97.91.198
  8   189 ms   191 ms   191 ms  202.97.52.222
  9   282 ms   277 ms   275 ms  202.97.49.106
 10   179 ms   179 ms   179 ms  64.62.244.61
 11   238 ms   253 ms   250 ms  72.52.92.121
 12   178 ms   178 ms   179 ms  66.220.18.42
跟踪完成。

Hong Kong:
PS C:\Users\xxxx> tracert -d 216.218.221.6
通过最多 30 个跃点跟踪到 216.218.221.6 的路由
  1    <1 毫秒   <1 毫秒   <1 毫秒 192.168.100.1
  2     1 ms     1 ms     1 ms  119.xxx.xxx.1
  3     2 ms     3 ms     3 ms  58.51.97.33
  4     4 ms     3 ms     3 ms  58.51.97.21
  5    17 ms     *       18 ms  202.97.67.49
  6    20 ms    18 ms    19 ms  202.97.33.118
  7     *        *       21 ms  202.97.91.206
  8   177 ms   174 ms     *     202.97.51.114
  9   230 ms     *      224 ms  202.97.50.26
 10   171 ms   170 ms   172 ms  64.62.244.61
 11   365 ms   362 ms   362 ms  184.105.64.126
 12  493 ms   332 ms   332 ms  216.218.221.6
跟踪完成。

[kcochran]

The site has done something similar for years.  When you go to create a tunnel, it makes a request to an IP assigned to every tunnel server.  Whichever one is 'closer' by your ISP's metrics will reply, and automatically be set as the default server to create a tunnel on.  In some cases this might not turn out to be the closest by latency, but should generally be pretty close to it, unless your ISP has some unusual routing decisions.