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.
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
跟踪完成。
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.