Re: Proposal: GETINFO controller option for connection information

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Fri, Jun 4, 2010 at 12:10 AM, Damian Johnson <atagar1@xxxxxxxxx> wrote:
> Hi Nick, thanks for the feedback!

Hi, Damian!  We're almost there, I think, with just a few points to clarify.

On xxx-circ-getinfo-option.txt:

* The spec addition isn't clear whether we mean all circuits, OR
circuits, or what.  I believe it's "all circuits", but it should say
so.

* 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.

* IN_TYPE/OUT_TYPE are specified as being an empty string if there are
no connections.  That's kind of fragile for parsing, since it would
mean that users could no longer fold multiple spaces into one like
they can for all the other control protocol formats .

* There's nothing specifying that "all" is not a valid identifier, so
"circ/all" is ambiguous. To be consistent with the rest of the getinfo
formats, let's say that the GETINFO key for a single circuit is
circ/id/<circid>, and the GETINFO for all circuits is circ/all.

* You clarified in your email that circ/all is a list of data in the
form given by circ/<ID> , but you didn't make that clarification in
your spec.

* There's no way to get notifications about new OR circuits, so any
program that wants to keep track of OR circuit state will need to
repeatedly poll circ/all.  Won't that be expensive on a busy server?
You wouldn't want to do it, say, once-per-second.  For consistency
with the rest of the controller protocol, OR circuit state changes
would probably want to be some kind of event.


On  xxx-getinfo-option-expansion.txt :

* By "relay/flags", what do you mean?  The flags held by the relay in
the current consensus, or something else?

* On "desc/time", why is it important to know the latest time we
fetched a server descriptor?

* On "desc/time", 'unix timestamp' is ambiguous; do you mean 'a
decimal integer expressing the current time in seconds since the Unix
epoch' or what?  I think the only other places in the control protocol
that express dates do so in ISO8601 format (YYYY-MM-DD HH:MM:SS,
relative to UTC).

* On "process/user", the spec needs to say what you mean by the
"user".  On Unix, is it a UID or a username?  What is it on windows?
The spec needs to say.  (You can't just have the controller tell from
context; on Unix at least, every valid decimal UID is also a valid
username.  If process/user tells me '0', am I running as root, or as a
user named "0"?)

* Also on process/user: If you meant "username", then there  should
indeed be an option to get all the *id stuff discussed upthread.

* Probably the spec needs to clarify that "process/pid" is the pid of
the _main_ Tor process, but that Tor might launch other processes from
time to time and you shouldn't be surprised if it does.

* Is "process/uptime-reset" affected by the SIGNAL command from the
controller?  The spec should  say.

yrs,
-- 
Nick