Feature Request - Periodic Route Re-Detection

[excessi0n]

Hi, thank you for sharing this great tool, I find myself using it all the time. It's especially nice to come back to it a week later and find it hasn't crashed! (Seemingly a common issue with some similar tools.)

As the topic suggests, it would be great to have an option to periodically re-detect the route, preferably in the background with a user settable increment. Then when a new route as been detected, update the ping destinations and possibly increment a counter of route changes.

I work for a wireless ISP and having an auto updating live path analysis would be really useful.

Thanks again.

Sam

[bp2008]

Hello! I'm glad you find it useful. I run several instances of PingTracer continuously myself and wouldn't be able to tolerate instability :)

Continously refreshed traceroute is actually something I had/have planned for "Ping Tracer 2.0" (a complete rewrite essentially from scratch). Unfortunately I never really got past an early proof of concept phase and that was over 3 years ago. Then I decided it would take too much work to build it into an easy, efficient, robust, and good looking solution, and I sort of abandoned the idea.

Ping Tracer 1.x was designed originally to just take one hostname as input, do one traceroute at the start, and then do regular pings to monitor each host that responded during the initial traceroute. Unfortunately the only way to make it do a new traceroute is to stop and start the pinging, which makes it lose all of its graph history because the app wasn't architected to be able to seamlessly transition from one set of hosts being monitored to another.

The way Ping Tracer 2.x was going to work, one instance of the program would be able to monitor as many different hosts as you want and each host could be monitored either by sequentially pinging only that host or by sequentially doing full traceroute operations against it. This would require me to optimize the traceroute operation so it could be performed much, much faster.

As you are probably aware, a traditional traceroute operation works by sending a sequence of pings to the destination, all with different TTL values (starting with TTL = 1, then TTL = 2, etc until the desired destination receives the ping and sends its reply). This is traditionally implemented to put an absolutely minimal load on the network, so it sends only one ping at a time, waits for a reply, then sends the next ping. This makes traceroute quite slow, especially for longer routes or when some of the hosts along the route do not send replies when the TTL expires.

So for PingTracer 2.x, I built it to send out all of the pings for the traceroute operation simultaneously. Of course this requires the program to guess how many pings will be needed. Guess too high and the final destination gets a lot of extra ping requests. Guess too low and the final destination doesn't receive any. When the route changes, the number of hosts in the route is likely to change. I had to take all of this into account to build PingTracer 2.x's core pinging module and it ended up working quite well.

But as I said, I never got past proof of concept.

Here is how far I got:

The method I devised to display the ping results was as a waterfall. Essentially a low resolution grid of colored blocks where the blocks are colored to indicate response time. The top left block is the response time of your closest router. The block to the right of that is the next router, and so on until the rightmost block which is either your final destination or just the last host to respond. Then every interval, a new row appears at the top of the waterfall and pushes all the previous results down.

The idea was you'd be able to click on any of the waterfalls to get a more detailed view, more like Ping Tracer 1.x has, with hostnames labeled and such. I never got as far as to implement any of that though. Lets just say there is a reason more-advanced software like PingPlotter costs money.

[bp2008]

Another core feature of Ping Tracer 2.0 was going to be the ability to select a process by name and then the program would monitor the routes to all of the hosts that process communicates with. So, e.g. if you were playing an online game and having network performance problems, you could select that game's process and not have to do any of the legwork of figuring out the game server's IP addresses in order to monitor the routes to them.

[excessi0n]

Hi! Thanks for responding so quickly.

Sounds like you had a bunch of great ideas for PT2, you clearly know what's desirable. I've always loved those waterfall style graphs, they really drew me to SDR and the wifi survey tools that include them make that analysis much more intuitive, seems a good fit for ping graphing.

For me, I'm not too bothered that the path discovery takes a little time. Though it occurs to me that you could possibly add graph targets as soon as they're discovered to make it feel snappier (rather than all at the end). In fact I'd also prefer to retain some indicator of a hop that wasn't responding to pings, just to keep the path data accurate, when I'm sharing that data with someone else.

It's interesting you mentioned PingPlotter, that's certainly the next thing I would compare PingTracer to and frankly having used both there are a number of ways I prefer PingTracer.

Reading through the comments here I discovered I can ping multiple static hosts with a comma separated list. That's going to be super useful too.

I'm happy to let you know I love PingTracer, it makes my life easier on a regular basis and has become a part of my toolkit I recommend to others. I've always gotten the most meaningful motivation hearing something I've crafted has made someone else's life better! Development is so often like labouring in the dark.

Hopefully this isn't too patronising, but I'm reminded of an aphorism I say to myself often:
Don't let perfect be the enemy of good.

Thanks again,

Sam