HN Explorer

Show HN: Faster-than-light ping (April Fools')

53 points by plingbang ↗ HN
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:

    ping ftlping.net
On Windows, add an option not to stop after 4 pings:

    ping -t ftlping.net
Works best on MacOS and FreeBSD. Not impressive on Windows but you can see something interesting if you run a packet analyser.

Report issues here: https://github.com/plingbang/ftlping/issues The code may be published when my future self passes it to me.

16 comments

[ 3.8 ms ] story [ 30.8 ms ] thread
keepamovin
This is fun. It's literally like back in the past:

  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 ms
zild3d
"somebody's printing up packets!"
btdmaster
Overflow in busybox ping!

  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
lxgr
Amazing!

I 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?

[deleted]
(comment deleted)
[deleted]
(comment deleted)
w3ll_w3ll_w3ll
Ubuntu

  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 ms
drpixie
Very nice. Takes a special mind to think about tweaking the contents of ping packets :)

Now, by rights, you've shown that I shouldn't trust anything I receive from anybody.

qwerty456127
Some years ago some papers were published claiming reliable quantum teleportation has finally been invented. This made me wonder if we are going to get microscopic pings over huge distances anytime soon.
avery17
Quantum teleportation is not real. The speed of light continues to stand as the ultimate limit of speed, information and causality.
qwerty456127
Can you elaborate on this? As I understand quantum teleportation is not real teleportation as people popularly understand teleportation - no piece of matter is teleported, yet it is real in the way we need - information is teleported instantly. In case I'm wrong, kindly hint on what is actually meant under quantum teleportation when we encounter papers about it.
renonce
Quantum teleportation does not allow you to transfer an amount of information faster than speed of light. Say you have two labs with two entangled particles 300000km away such that when one particle is “up” the other will be “down”. When lab A observes the particle it has 1/2 probability of being “up” and 1/2 probability of being “down”. Same for lab B. But once both observations are known by someone C (could also be A or B), C will find that one of the particles is “up” and the other is “down”. Bell’s theorem further tells us that there are cases (probability distributions of A and B) where the distribution could not be explained by assuming that the probability distribution of A and B is determined before observation.

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.

cchance
HAHA thats pretty cool even as just a concept to show how ping works and can be manipulated.