yvs2014

adaptation of this cache-mode mentioned in previous message to current mtr https://github.com/yvs2014/mtr085/tree/mtr20230314-with-cachemode

> caching the same data so that multiple copies of mtr could use it in parallel it's far enough out of scope mtr itself, and a bit complicated because of...

> not flood our poor router a bit calculations with the longest imaginable path (30 hops): -- without cache it's 30 packets per second (30 pps) on permanent basis --...

@PenelopeFudd You're welcome in addition I've combined two cache options in one (-X/--cache SECONDS), maybe it's a bit more common with a short option @rewolff Could this cache mode be...

> The mtr test performed with the second command are much much faster. It's a feature connected with wait time calculation between packet sending (like `mtr -f 32 127.1`) A...

Just btw, does GeoIP2 have online API? (If so, are there some restrictions like number of queries, etc.) Comparing to (idk, for example, to IP-API) is it provided more data?...

@JDarzan − there's not so many queries in an ordinary trace − in case of using dns api, those replies are usualy cached by local dns server in many cases...

> sqlite is "low overhead". Just a library putting things in a file ... Anyway it needs some external databases working with persistent storage. On other hand, keeping a couple...

> The return packets just aven't arrived yet.... When can you decide a packet has defintively been lost? > Of course we could consider say 5, 10 or 30 seconds...

> always call the "seal" function. Assuming that bell functionality will be used very rarely, the cost of function call is too excessive in relation to resources. Kinda "if (a)...