> "You may have noticed that the traceroute progressively loads in lines above the bottom line. Web pages can only load forward. Since I didn’t want to use any JavaScript, I did the hackiest thing possible: every time I update the traceroute display, I embed a CSS block that hides the previous iteration! Since browsers render CSS as the page is loading, this made it look like the traceroute was being edited over time."
> This reverse traceroute is still helpful. The paths will be roughly the same, likely differing only in terms of which specific routers see your packet.
This is categorically incorrect. While the AS path is often the same, the actual peering points are almost always quite different. Most ASes use hot-potato routing - getting packets to the next AS at the closest peering point to the source of the traffic. (And even if cold-potato routing is used, that's still asymmetric). In addition if there are two options with the same AS-path-length hot-potato routing can lead to different AS paths. This can happen if there's two mutual transit providers between source and destination and various other situations.
> Seems like this hit the Hacker News front page again, and the server's having some trouble pinging all of you. Feel free to read the article, but if you want to see your tracereoute you might need to bookmark and check back tomorrow :)
Hmm, after several seconds it gave up and displayed raw markup ... I'm not sure exactly why in this case, but ...
One of the major infelicities of the web is that CSS is specified to ignore truncation, and there is no way to fix this. Now think about what happens if something like `display: inline-block` gets truncated before the `-`.
I have old components on my personal site that used to do a similar trick for streaming data without JavaScript but between nginx buffering and cloudflare I have not been able to sort out getting it to actually work these days. Worked fine on Apache in 2005 lol
> This isn’t actually a “time” as implied by a name — it’s a countdown! Every time a router forwards an ICMP packet along, it’s supposed to decrement the TTL number.
No, it's actually a time, it's just that it has a precision of 1 second.
RFC 791: "The time is measured in units of seconds, but since every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second, the TTL must be thought of only as an upper bound on the time a datagram may exist."
28 comments
[ 3.7 ms ] story [ 52.7 ms ] threadhttps://news.ycombinator.com/item?id=38531604
Love this
This is categorically incorrect. While the AS path is often the same, the actual peering points are almost always quite different. Most ASes use hot-potato routing - getting packets to the next AS at the closest peering point to the source of the traffic. (And even if cold-potato routing is used, that's still asymmetric). In addition if there are two options with the same AS-path-length hot-potato routing can lead to different AS paths. This can happen if there's two mutual transit providers between source and destination and various other situations.
(EDIT: fixed hot/cold mixup)
> - Lexi, Nov 7, 3:16 PM PST
One of the major infelicities of the web is that CSS is specified to ignore truncation, and there is no way to fix this. Now think about what happens if something like `display: inline-block` gets truncated before the `-`.
I read this title and that opening bass line just starts flowing.
Traceroute isn't real, or: Whoops! Everyone Was Wrong Forever: https://gekk.info/articles/traceroute.htm
No, it's actually a time, it's just that it has a precision of 1 second.
RFC 791: "The time is measured in units of seconds, but since every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second, the TTL must be thought of only as an upper bound on the time a datagram may exist."