5 ms·
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:
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.
- stanac 3y agoOn windows after some time I am getting: Request 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
- josephcsible 3y agohttps://github.com/iputils/iputils/blob/294a65f00047f31685b7dd07048b48c4be82e097/ping/ping_common.c#L752-L763 https://github.com/iputils/iputils/blob/294a65f00047f31685b7...
- keepamovin 3y agoThis 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 3y ago"somebody's printing up packets!"
- btdmaster 3y agoOverflow 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 3y agoAmazing! 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 3y ago[deleted]
- deleted 3y ago[deleted]
- w3ll_w3ll_w3ll 3y agoUbuntu 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 3y agoVery 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 2y agoSome 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 2y agoQuantum teleportation is not real. The speed of light continues to stand as the ultimate limit of speed, information and causality.
- qwerty456127 2y agoCan 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 2y agoQuantum 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 2y agoHAHA thats pretty cool even as just a concept to show how ping works and can be manipulated.
- flysand7 2y agoI'm getting a timeout :)