"Our Info" section in network database missing details; clarify stat\_tunnel stats #443

New Issue

idk · 2025-04-21T15:10:22-04:00

idk commented

2025-04-21 15:10:22 -04:00

Opened 3 years ago

Last modified 3 years ago

#2142 new defect

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

Reported by:ReportageOwned 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

Opened [3 years ago](/timeline?from=2018-01-29T14%3A12%3A16Z&precision=second "See timeline at Jan 29, 2018 2:12:16 PM") Last modified [3 years ago](/timeline?from=2018-02-01T13%3A27%3A21Z&precision=second "See timeline at Feb 1, 2018 1:27:21 PM") ## [\#2142](/ticket/2142)[new](/query?status=new)[defect](/query?status=!closed&type=defect) # "Our Info" section in network database missing details; clarify stat\_tunnel stats Reported by:[Reportage](/query?status=!closed&reporter=Reportage)Owned by:[zzz](/query?status=!closed&owner=zzz) Priority: [minor](/query?status=!closed&priority=minor) Milestone: [undecided](/milestone/undecided "No date set") Component: [router/netdb](/query?status=!closed&component=router%2Fnetdb) Version: [0.9.32](/query?status=!closed&version=0.9.32) Keywords: [netdb](/query?status=!closed&keywords=~netdb), [our](/query?status=!closed&keywords=~our) [info](/query?status=!closed&keywords=~info), [UX](/query?status=!closed&keywords=~UX) Cc: Parent Tickets: Sensitive: [no](/query?status=!closed&sensitive=0) ### 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

idk added this to the undecided milestone 2025-04-21 15:10:22 -04:00

idk added the

labels 2025-04-21 15:10:22 -04:00

idk commented

2025-04-21 15:10:22 -04:00

comment:3 Changed 3 years 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.

[comment:3](https://trac.i2p2.de/\#comment:3) Changed [3 years ago](https://trac.i2p2.de//timeline?from=2018-02-01T13%3A27%3A21Z&precision=second "See timeline at Feb 1, 2018 1:27:21 PM") 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.

idk commented

2025-04-21 15:10:22 -04:00

comment:2 Changed 3 years ago by Reportage

Status:infoneeded_new →
new

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:2](https://trac.i2p2.de/\#comment:2) Changed [3 years ago](https://trac.i2p2.de//timeline?from=2018-02-01T04%3A38%3A28Z&precision=second "See timeline at Feb 1, 2018 4:38:28 AM") by Reportage Status:infoneeded\_new → new 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?

idk commented

2025-04-21 15:10:23 -04:00

comment:1 Changed 3 years ago by zzz

Status:new →
infoneeded_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:1](https://trac.i2p2.de/\#comment:1) Changed [3 years ago](https://trac.i2p2.de//timeline?from=2018-01-30T11%3A53%3A33Z&precision=second "See timeline at Jan 30, 2018 11:53:33 AM") by zzz Status:new → infoneeded\_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.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: I2P_Developers/i2p.i2p#443

"Our Info" section in network database missing details; clarify stat\_tunnel stats #443

#2142newdefect

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

Description

Subtickets

#2142 new defect