Show HN: Faster-than-light ping (April Fools') A server that replies to your pings faster than ever! Now with IPv6 support. Give it a minute and the response time will go down tremendously: Report issues here: https://github.com/plingbang/ftlping/issues The code may be published when my future self passes it to me. |
64 bytes from 82.165.188.205: seq=0 ttl=52 time=172.825 ms
64 bytes from 82.165.188.205: seq=1 ttl=52 time=182.433 ms
64 bytes from 82.165.188.205: seq=2 ttl=52 time=221.810 ms
64 bytes from 82.165.188.205: seq=3 ttl=52 time=96.547 ms
64 bytes from 82.165.188.205: seq=4 ttl=52 time=89.722 ms
64 bytes from 82.165.188.205: seq=5 ttl=52 time=77.812 ms
64 bytes from 82.165.188.205: seq=6 ttl=52 time=68.624 ms
64 bytes from 82.165.188.205: seq=7 ttl=52 time=57.501 ms
64 bytes from 82.165.188.205: seq=8 ttl=52 time=48.275 ms
64 bytes from 82.165.188.205: seq=9 ttl=52 time=37.498 ms
64 bytes from 82.165.188.205: seq=10 ttl=52 time=22.236 ms
64 bytes from 82.165.188.205: seq=11 ttl=52 time=23.625 ms
64 bytes from 82.165.188.205: seq=12 ttl=52 time=9.215 ms
64 bytes from 82.165.188.205: seq=13 ttl=52 time=4.496 ms
64 bytes from 82.165.188.205: seq=14 ttl=52 time=5.311 ms
64 bytes from 82.165.188.205: seq=15 ttl=52 time=3.678 ms
64 bytes from 82.165.188.205: seq=16 ttl=52 time=3.261 ms
64 bytes from 82.165.188.205: seq=17 ttl=52 time=4294933.513 ms
64 bytes from 82.165.188.205: seq=18 ttl=52 time=4294938.415 ms
64 bytes from 82.165.188.205: seq=19 ttl=52 time=3.640 ms 64 bytes from 82.165.188.205: icmp_seq=40 ttl=50 time=18.069 ms
64 bytes from 82.165.188.205: icmp_seq=41 ttl=50 time=-47.262 ms
64 bytes from 82.165.188.205: icmp_seq=42 ttl=50 time=-62.118 ms
64 bytes from 82.165.188.205: icmp_seq=43 ttl=50 time=-123.935 ms
64 bytes from 82.165.188.205: icmp_seq=44 ttl=50 time=-130.247 ms
64 bytes from 82.165.188.205: icmp_seq=45 ttl=50 time=-141.351 ms
64 bytes from 82.165.188.205: icmp_seq=46 ttl=50 time=-98.121 ms
64 bytes from 82.165.188.205: icmp_seq=47 ttl=50 time=-141.229 ms
64 bytes from 82.165.188.205: icmp_seq=48 ttl=50 time=-170.218 ms
64 bytes from 82.165.188.205: icmp_seq=49 ttl=50 time=-186.823 ms
64 bytes from 82.165.188.205: icmp_seq=50 ttl=50 time=-176.823 ms
64 bytes from 82.165.188.205: icmp_seq=51 ttl=50 time=-207.752 ms
64 bytes from 82.165.188.205: icmp_seq=52 ttl=50 time=-223.770 ms
64 bytes from 82.165.188.205: icmp_seq=53 ttl=50 time=-223.758 ms
64 bytes from 82.165.188.205: icmp_seq=54 ttl=50 time=-149.182 ms
64 bytes from 82.165.188.205: icmp_seq=55 ttl=50 time=-227.685 ms
64 bytes from 82.165.188.205: icmp_seq=56 ttl=50 time=-263.873 ms
64 bytes from 82.165.188.205: icmp_seq=57 ttl=50 time=-258.082 msI can imagine how it works on the server side, but what's really fascinating is that my client (macOS) can handle negative response times at all.
Does anybody know how that's possible? Do ICMP sockets just queue incoming "responses" until there is a pending matching request?
Or does the ping command take complete ICMP "ownership" over... something? more than a socket? while it runs, and this is an implementation quirk of that userspace tool's synchronization/threading/event handling mechanisms?
PING ftlping.net (82.165.188.205) 56(84) bytes of data.
64 bytes from rfc6921.net (82.165.188.205): icmp_seq=1 ttl=49 time=131 ms
64 bytes from rfc6921.net (82.165.188.205): icmp_seq=2 ttl=49 time=121 ms
64 bytes from rfc6921.net (82.165.188.205): icmp_seq=3 ttl=49 time=110 ms
64 bytes from rfc6921.net (82.165.188.205): icmp_seq=4 ttl=49 time=88.0 ms
64 bytes from rfc6921.net (82.165.188.205): icmp_seq=5 ttl=49 time=105 ms
64 bytes from rfc6921.net (82.165.188.205): icmp_seq=6 ttl=49 time=80.5 ms
64 bytes from rfc6921.net (82.165.188.205): icmp_seq=7 ttl=49 time=69.9 ms
64 bytes from rfc6921.net (82.165.188.205): icmp_seq=8 ttl=49 time=58.6 ms
64 bytes from rfc6921.net (82.165.188.205): icmp_seq=9 ttl=49 time=55.8 ms
64 bytes from rfc6921.net (82.165.188.205): icmp_seq=10 ttl=49 time=40.1 ms
64 bytes from rfc6921.net (82.165.188.205): icmp_seq=11 ttl=49 time=30.7 ms
64 bytes from rfc6921.net (82.165.188.205): icmp_seq=12 ttl=49 time=20.6 ms
ping: Warning: time of day goes back (-7859us), taking countermeasures
ping: Warning: time of day goes back (-7746us), taking countermeasures
64 bytes from rfc6921.net (82.165.188.205): icmp_seq=13 ttl=49 time=0.000 ms
64 bytes from rfc6921.net (82.165.188.205): icmp_seq=14 ttl=49 time=18.7 ms
ping: Warning: time of day goes back (-8431us), taking countermeasures
64 bytes from rfc6921.net (82.165.188.205): icmp_seq=15 ttl=49 time=0.000 ms
ping: Warning: time of day goes back (-17099us), taking countermeasures
64 bytes from rfc6921.net (82.165.188.205): icmp_seq=16 ttl=49 time=0.000 ms
ping: Warning: time of day goes back (-27144us), taking countermeasures
64 bytes from rfc6921.net (82.165.188.205): icmp_seq=17 ttl=49 time=0.000 msRequest timed out.
And on linux:
ping: Warning: time of day goes back (-173217us), taking countermeasures 64 bytes from [redacted]: icmp_seq=31 ttl=55 time=0.000 ms
Now, by rights, you've shown that I shouldn't trust anything I receive from anybody.
There are never ending debates on what happened while observing A, but I dislike calling it “quantum teleportation” as it only further confuses people as if any information was teleported during observation. My theory is that A and B are totally independent until both observations reach a middleman C, and it’s at this point that the entanglement starts to matter.