Opened 22 months ago

Last modified 22 months ago

#2142 new defect

"Our Info" section in network database missing details; clarify stat_tunnel stats

Reported by: Reportage Owned by: zzz
Priority: minor Milestone: undecided
Component: router/netdb Version: 0.9.32
Keywords: netdb, our info, UX Cc:
Parent Tickets: Sensitive: no

Description

The following details are missing from "Our Info" in the network database and should be considered for inclusion:

  • Addresses (NTP, SSU) and associated info (displayed in other routers)
  • Stats section: netdb.knownLeaseSets, netdb.knownRouters, family, familyKey, familySig (if family set)
  • Stats section (if advanced console mode is enabled): stat_tunnel.buildExploratoryExpire.60m, stat_tunnel.buildExploratoryReject.60m, stat_tunnel.buildExploratorySuccess.60m, stat_tunnel.participatingTunnels.60m

Furthermore, the stat_tunnel stats could use some clarification, as the presentation is opaque eg: 328.07;328.07;149.06%;555;555;555; The trailing semicolon is unneeded, and it's not immediately clear what the figures and percentage refers to.

Subtickets

Change History (3)

comment:1 Changed 22 months ago by zzz

Status: newinfoneeded_new

You may be confused about the netdb router info page. This is not a generalized info/stats page, this is what's actually in the network database. If addresses or stats are not shown for your router, that means that you didn't publish that info to the netdb. The stat values are not necessarily meaningful for viewing. That's why you have to have advanced set to see them.

We use the same method to display the 'our router' section as for the others. They aren't formatted differently - except that, apparently, the stats section is displayed for 'our router' whether advanced or not.

Not sure what we could do differently here.

comment:2 Changed 22 months ago by Reportage

Status: infoneeded_newnew

The Addresses line is missing the router's IP address (host) and port, and only shows the Ihosts and Iports. The addition of the router's IP(s) (SSU/NTCP) and a country flag would bring it up to parity with other routers.

The stats section could pull in local data to indicate known routers and known leasesets, again to bring it up to parity with other routers (floodfills) as the information is known, albeit not published to the netDB if our router is not a floodfill.

As for presentation, host and port should be paired, and other tags prioritized in order of relevance/relationship eg. Host: [] Port: [] Mtu: [] Caps: [] Key: [] Cost: [] /n Ihostx: [] Iportx: [] IKeyx: [] Itagx: [] Ihosty: [] etc. The SSU/NTCP entries could follow a predictable pattern to make for easier reading, so SSU entries always precede NTCP entries for a given router id, for example.

And if stat values are not meaningful for viewing, why not make them meaningful? The stat_tunnel.x stats at least have a percentage, although it's not clear what it's referencing. The tunnel build stats could be simplified (parsed) so they can be easily understood, and the participating tunnel stats could benefit from the same treatment. The "Cost" value could also benefit from some explanation. Perhaps a section on the help page with an explanation of the tags and values would be helpful?

comment:3 Changed 22 months ago by zzz

If you are firewalled or hidden, you don't publish a host/port. ihost/iport are introducers. Again, this is what's published. If we don't have an IP address to do GeoIP lookup, we can't display a flag. For the 'our info' we could use our known IP address if firewalled, I'm not sure if that's useful. Or even confusing - would the user think we are publishing the country when we aren't?

The addresses and options are displayed in the order they are in the netdb entry. I do agree it would be nice to sort the addresses.

Cost should probably be hidden unless in advanced mode, it's not worth explaining.

Note: See TracTickets for help on using tickets.