tahoe-lafs/trac-2024-07-25

Grid Status displays wrong Address of connected storage servers #2818

New issue

Closed

opened 2016-09-02 11:29:54 +00:00 by dawuud · 6 comments

dawuud commented

2016-09-02 11:29:54 +00:00

Owner

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:

UNIXAddress('/var/run/tor/socks')

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: *UNIXAddress('/var/run/tor/socks')*

tahoe-lafs added the

labels 2016-09-02 11:29:54 +00:00

tahoe-lafs added this to the undecided milestone 2016-09-02 11:29:54 +00:00

tahoe-lafs changed title from ~~Grid Status display wrong Address of storage servers~~ to Grid Status displays wrong Address of storage servers

2016-09-02 11:41:16 +00:00

tahoe-lafs changed title from ~~Grid Status displays wrong Address of storage servers~~ to Grid Status displays wrong Address of connected storage servers

2016-09-02 11:41:41 +00:00

dawuud commented

2016-09-02 12:04:28 +00:00

Author

Owner

please review
https://github.com/tahoe-lafs/tahoe-lafs/pull/331

please review <https://github.com/tahoe-lafs/tahoe-lafs/pull/331>

tahoe-lafs modified the milestone from undecided to 1.12.0

2016-09-02 17:22:39 +00:00

warner commented

2016-09-02 17:45:43 +00:00

Author

Owner

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.

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.

warner commented

2016-09-02 18:09:46 +00:00

Author

Owner

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

[Foolscap#267](https://foolscap.lothar.com/trac/ticket/267) added to track a new API for this, although I think we should land this first, and think about enhancements later.

warner commented

2016-09-02 18:11:52 +00:00

Author

Owner

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:127.0.0.1:62848', 'tcp:10.0.1.43:62848', 'tcp:10.0.1.57:62848']

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.

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:127.0.0.1:62848', 'tcp:10.0.1.43:62848', 'tcp:10.0.1.57:62848'] ``` 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.

Brian Warner <warner@lothar.com> commented

2016-09-02 18:14:39 +00:00

Author

Owner

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

In [f88ae38/trunk](/tahoe-lafs/trac-2024-07-25/commit/f88ae3861a835b086b19e8f7e448a080c67a6715): ``` 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 ```

tahoe-lafs added the

fixed

label 2016-09-02 18:14:39 +00:00

Brian Warner <warner@lothar.com> closed this issue

2016-09-02 18:14:39 +00:00

warner commented

2016-09-02 18:21:33 +00:00

Author

Owner

I added #2819 for the beautification step.