[HN Gopher] Show HN: Faster-than-light ping (April Fools')
___________________________________________________________________
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.
Author : plingbang
Score : 36 points
Date : 2024-04-01 11:08 UTC (11 hours ago)
| stanac wrote:
| On 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 wrote:
| https://github.com/iputils/iputils/blob/294a65f00047f31685b7...
| keepamovin wrote:
| 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 wrote:
| "somebody's printing up packets!"
| btdmaster wrote:
| 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 wrote:
| 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?
| w3ll_w3ll_w3ll wrote:
| 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
___________________________________________________________________
(page generated 2024-04-01 23:02 UTC)