[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

RE: controller GETINFO ns/id/fingerprint "s" record

> On Tue, May 27, 2008 at 02:19:22PM -0700, Wesley Kenzie wrote:
> > >"where does the data originate from when the controller GETINFO 
> > >command is used?  Does it just grab data out of the 
> cached* files on 
> > >disk?  Or poll one of the directory authorities?  Or 
> something else?"
> > 
> > I am still waiting for someone to help with this question.  Using a 
> > controller interface, when I issue a GETINFO ns/id/* or GETINFO 
> > desc/id/* command where does the response data come from?  Does it 
> > just come out of the cloud from one of the directory authorities?  
> > Does it get read from the local cached* file(s)?  Does it get 
> > calculated dynamically in real time?
> It gets answered by your local Tor process based on the 
> directory information that it has locally. It doesn't trigger 
> any new fetches.

Thanks, Roger.

> > I have recently been doing some timings of the controller 
> interface, 
> > and find that on average I can get a response to one of 
> these GETINFO 
> > commands in less than 0.06 seconds, and sometimes in as little as 
> > 0.0001 seconds. However there are times when it takes up to 20+ 
> > seconds to get this same data.  I am struggling to understand what 
> > might be going on here...
> Do you mean that the getinfo command hangs for 20 seconds and 
> then answers? Or that getinfo tells you it doesn't have an 
> answer, and up to 20 seconds passes, with you continually 
> doing new getinfos, before you get the answer you want?
> If the former, that sounds like a bug, and you should give us 
> debug-level logs with details. If the latter, it sounds like 
> you're asking for data that your Tor doesn't have yet.
> --Roger

I am not sure which condition applies, but will do some further tests.  My
best guess is that I have to sometimes wait 20 seconds to get an answer.  If
the Tor process is reading data from the local cache then perhaps the server
is too busy to get to this file read right away (I am dealing with sometimes
very heavy server loads).