Hi!
So, for a long time, Tor servers put information in server descriptors
that Tor clients didn't actually use. The biggest offenders were the
read-history and write-history lines: they account for around 60% of
the size of a big set of compressed servers. By removing these lines,
we can save an enormous proportion of directory bandwidth, and (I
hope) support more clients at a time.
But what about the tools that use this information?
Tor 0.2.0.x has a feature called "extra-info" documents. This is an
adjunct descriptor that gets published along side the main server
descriptor. Clients don't download it by default. We now put
bandwidth history information there. Soon, extra-info documents will
be the _only_ place to find bandwidth history information, once
routers start omitting it from their regular descriptors.]
[For the full details of the decisions involved above, see proposal
104 at
http://tor.eff.org/svn/trunk/doc/spec/proposals/104-short-descriptors.txt
]
I'd like to get torstatus updated to handle extra-info before it starts
getting bandwidth history. To make this easier, I've added a GETINFO
item:
GETINFO desc/all-recent-extrainfo-hack
It gives the same result as desc/all-recent, except that it looks into
any appropriate locally available extrainfo documents and adds
bandwidth history lines that it found there. (The signature is no
longer valid, of course, but parsing should still work.)
So, to keep torstatus's bandwidth history info from breaking, here's
the procedure to follow:
1) Use Tor 0.2.0.6-alpha or later.
2) Switch GETINFO desc/all-recent to
GETINFO desc/all-recent-extrainfo-hack
3) Set "DownloadExtraInfo 1" in the tor process's configuration.
(Later, it would be better to go back to GETINFO desc/all-recent, look
at the extra-info-digest line in the original descriptor, and then
GETINFO extra-info/<DIGEST> to get the bandwidth information. But I
wanted to provide something fast so that updating the code would be
easy.)
In all likelihood, servers will start dropping bandwidth history
information from their descriptors in about 2-4 weeks from now. Is
that enough time? We'd really like to get the directory bandwidth
savings on the 0.2.0.x timeframe, but we don't want to break existing
code in doing so if we can possibly help it.
yrs,
--
Nick Mathewson
Attachment:
pgpXYdg0eGPJ5.pgp
Description: PGP signature