[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Attn TorStatus folks! We are about to break your bandwidth measures!
- To: or-talk@xxxxxxxxxxxxx, "Nick Mathewson" <nickm@xxxxxxxxxxxxx>
- Subject: Re: Attn TorStatus folks! We are about to break your bandwidth measures!
- From: "Kasimir Gabert" <kasimir.g@xxxxxxxxx>
- Date: Mon, 27 Aug 2007 17:11:53 -0600
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-talk-outgoing@xxxxxxxx
- Delivered-to: or-talk@xxxxxxxx
- Delivery-date: Mon, 27 Aug 2007 19:12:02 -0400
- Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=W4hhM1EhbploJDVzeJXs81rZsen08Hq3ld6ZX1gP3C+Ht30Pr4YObjjOw+jvt6CE57JCt8tK+L66QKsDbc1ck//4cCc9YCX3IL6/hgnTsst+Ke6crGixpDclkx1fuYdlHOLpWNsGeNjmMKXl3TIrorI5V56qUuTY+6Y/EptyStw=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=s8RyRcCpQXl8w/0ynz+W4yCYoQRIkG8tMIwnkHwqRYODkbbbby7qZd5fSm5wgQF9Sw3Pas1usfnQGNsZ45E1PntsA4+amTi0vcjx/Ut2c169xYlI+GFZQuqYpI3oCYnr8ss2uHLTqPOH7DS6UOeB8jIFMWDx6oXNrWFi4U74ito=
- In-reply-to: <20070827225352.GA14563@xxxxxxxxxxxxxxxxxx>
- References: <20070827225352.GA14563@xxxxxxxxxxxxxxxxxx>
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
Hello Nick Mathewson,
Thank you very much for letting me know about this upcoming change.
I will get TorStatus to work with this new version, and release an
update, within the next few days.
2-4 weeks should be enough time to get most of the servers running the
new version of Tor and TorStatus.
Thanks again,
Kasimir Gabert
On 8/27/07, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
> 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
>
>
--
Kasimir Gabert