Grid Status displays wrong Address of connected storage servers #2818

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
unknown
normal
defect
1.11.0
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>
warner was assigned by tahoe-lafs 2016-09-02 12:04:44 +00:00
warner modified the milestone from undecided to 1.12.0 2016-09-02 17:22:39 +00:00

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.

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.

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.

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

I added #2819 for the beautification step.

I added #2819 for the beautification step.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#2818
No description provided.