Re: Proposal: GETINFO controller option for connection information

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Thu, Jun 24, 2010 at 1:34 AM, Damian Johnson <atagar1@xxxxxxxxx> wrote:
> Hi Nick. Thanks for the comments!
>
>> * IN_TYPE/OUT_TYPE talk about the type of an inbound/outbound
>> "connection."  Do you mean circuits, or connections on the circuits?
>> Either way I'm confused.  For example, a control connection is never
>> attached to a circuit at all.
>
> Yea, that isn't really appropriate and was making the spec messier than it
> needed to be. Replaced with a single TYPE parameter to indicate the
> placement in the circuit (guard/bridge, relay, exit, or one-hop in case
> they're allowing them).

Hm.  But we don't necessarily know this.  Our "are we client-facing"
tests are approximate, not certain, and the only way to tell whether
we're intermediate or exiting is to wait and see if we're told to
exit.  In fact, the leaky-pipe topology means that we're potentially
intermediate _and_ exiting on a single circuit.

Also, it's still a tiny bit ambiguous: some people consider a circuit
used for a rendezvous point as an exit, and some don't.

The only other change I'd suggest to xxx-circ-getinfo-option.txt is to
consider using named parameters (like "WRITE=9090") rather than
positional parameters ('The third value is the write one').  This has
turned out to make it way easier to expand events in the future.
(Consider what would happen if we wanted to add another field to
RCIRC.)

Also, maybe rename the "circ" GETINFO to "rcirc" for consistency?

On xxx-getinfo-option-expansion.txt :

>> * On "desc/time", why is it important to know the latest time we
>> fetched a server descriptor?
>
> There's some interesting information here such as your relay's observed
> bandwidth. However, there's no way of telling how stale information provided
> by the "desc/id/*" is, and since most relays stop fetching descriptors after
> a time it's often hideously ancient.

There totally is a way to tell how old a descriptor is: you just look
at the "published" field on the descriptor, and that tells you when it
was first uploaded to the authorities.

If it's important to tell when you _fetched_ the descriptor (as
opposed to when it was first published), we do store that information,
but it should be made available on a per-descriptor basis, right?
That would be more useful.

> What I'd really like an option to manually refresh descriptors (both
> individually and as a batch call), however since I was aiming to keep this
> proposal limited to GETINFO options it seemed inappropriate. Do you have any
> thoughts on this sort of functionality? What section of the control-spec
> would it go under?

It sounds like it should be a torrc option saying "Don't stop
refetching descriptors when there's no network activity."  Actually,
do we have one of those already?

>> * Also on process/user: If you meant "username", then there  should
>> indeed be an option to get all the *id stuff discussed upthread.
>
> I'm sure this is a dumb question but... why? I've never had use for the
> numeric uid, let alone the three other varieties Jake mentioned (actually,
> never heard of them before...). If you can think of use cases in which
> they're useful then by all means include them. However, I don't particularly
> care about that information.

For unixy programs, it's way easier to work with uids than with
usernames.  The other varieties are useful for telling you about Tor's
setuid/setgid state.

Other than that, looks good.
-- 
Nick