#2818 closed defect (fixed)

Grid Status displays wrong Address of connected storage servers

Reported by: dawuud Owned by: warner
Priority: normal Milestone: 1.12.0
Component: unknown Version: 1.11.0
Keywords: tor Cc:
Launchpad Bug:


I am connected to the public grid using our recently merged Tor integration features... however the grid status displays each storage server's address as:


Change History (10)

comment:1 Changed at 2016-09-02T11:41:16Z by dawuud

  • Summary changed from Grid Status display wrong Address of storage servers to Grid Status displays wrong Address of storage servers

comment:2 Changed at 2016-09-02T11:41:41Z by dawuud

  • Summary changed from Grid Status displays wrong Address of storage servers to Grid Status displays wrong Address of connected storage servers

comment:4 Changed at 2016-09-02T12:04:44Z by dawuud

  • Owner set to warner

comment:5 Changed at 2016-09-02T17:22:39Z by warner

  • Milestone changed from undecided to 1.12.0

comment:6 Changed at 2016-09-02T17:45:43Z by warner

Hm. Let's see.. this is just for client->server connections, and since the client is using unique Tubs (which aren't listening) for those connections, the connected address will always be that of the far end. Previously, by using a single shared (listening) Tub for all connections, sometimes the "client->server" connection would actually be running over a TCP connection that was initiated by the server (when both sides are running servers). At that time, it was useful to know whether your TCP connection was outbound or inbound. But since now they're always outbound, I guess we don't need to display the difference anymore.

There's two pieces of information that would be useful on this display. The first is where the server is advertising themselves (the connection hint). The second would be something about how we actually managed to connect to them.

It might be nice if this showed the fact that you're using Tor to connect to them. That's going to need some new Foolscap support though.. maybe it could remember which connection-handler was successful, and stash it on the Broker somewhere. Then we could add a new API (rref.getConnectionInfo?) which reported the name of the connection-handler and the hint which it used, maybe some other descriptive text.

I guess the only problem with displaying the connection hints is that they're slightly longer (tcp:HOST:PORT instead of HOST:PORT). Not a big deal.

comment:7 Changed at 2016-09-02T18:09:46Z by warner

Foolscap#267 added to track a new API for this, although I think we should land this first, and think about enhancements later.

comment:8 Changed at 2016-09-02T18:11:52Z by warner

Hm, this patch is also a bit ugly when the server has multiple connection hints (which is what tub.location=AUTO always does). My test node (using direct TCP connections) is currently showing:

['tcp:', 'tcp:', 'tcp:']

which gets wrapped into the little box, and doesn't tell me which of those connections actually got used.

I guess it's better than UNIXAddress, though. I think I'll land this and then prioritise adding the new Foolscap API to make it nicer, and see if I can get that into the next release.

comment:9 Changed at 2016-09-02T18:14:39Z by Brian Warner <warner@…>

  • Resolution set to fixed
  • Status changed from new to closed

In f88ae38/trunk:

Make the grid status display the location hints

Instead of displaying what appears to be the remote peer address
we display the list of connection hints.

closes ticket:2818

comment:10 Changed at 2016-09-02T18:21:33Z by warner

I added #2819 for the beautification step.

Note: See TracTickets for help on using tickets.