id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
267	add rref.getConnectionInfo ?	Brian Warner		"In [https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2818 tahoe#2818], dawuud noticed that the Tahoe ""connected servers"" list was rendering ugly things like `UNIXAddress('/var/run/tor/socks')` for servers which had used a (unix-domain) Tor SOCKS connection handler. This display uses `rref.getPeer()`, which usually returns a `twisted.internet.address.IPv4Address`. That ticket is about switching tahoe to use `rref.getLocationHints()` instead, which provides more information about the intended target of the original FURL.

(Tahoe client+server nodes used to run client data over a TCP connection initiated by the server, since they used to share a Tub for both purposes. So `getPeer()` was handy to discover whether you were using an outbound connection to them, or re-using an inbound connection they'd made to you. But Tahoe doesn't use the same Tub for those two purposes anymore, so it no longer needs a way to display the distinction)

However it would be useful (and perhaps comforting) to report exactly *how* the server connection was made: which connection handler was in charge. E.g. it'd be nice to know that we're using Tor to connect to a TCP hint.

So maybe we should add a new API, like `rref.getConnectionInfo()`, which would report:

* which hint was successful
* which connection handler managed that hint (as a short string)

It might be interesting to include when the connection was established, but we've already got `rref.getDataLastReceivedAt`, which is arguably more precise (connections being an illusion, after all).

Maybe `rref.describeConnection()`, which could return a string like `tcp(HOST:PORT)` or `tor(HOST:PORT)`. This string would be provided by the connection handler by a new API (a sibiling of `hint_to_endpoint`) that would take the hint and return a string (independent of returning an endpoint). Or maybe we change the `hint_to_endpoint` API to return a 3-tuple (negotiation_hostname, endpoint, description). For backwards compatibility, we could either add a new method name, or use the old one but add a kwarg to ask for the 3-tuple instead of the old 2-tuple. In any case, these description strings would be fetched when we get the endpoint, then stored on the Broker if/when the endpoint wins negotiation, so we don't keep a reference to the connection handler after all the endpoints have been generated.

Would it be useful for the caller to get parsed components of the description? The handler name could work this way, but the other information might be very handler-specific (tcp and tor have HOST and PORT, i2p has HOST but PORT is optional, and other transports in the future might not have HOST or PORT at all). Maybe a dictionary that has ""description"" as a composite string, ""handler"" as a string, and other arguments that depend on the handler type. So renderers could do specific things if they recognize the handler, but fall back on the composite string if they don't.
"	enhancement	closed	major	0.12.5	network	0.12.3	fixed