Thus spake Roger Dingledine (arma@xxxxxxx): > On Sun, Dec 13, 2009 at 08:23:14PM -0500, Roger Dingledine wrote: > > I've been pondering other performance improvements. One of them is to > > rate-limit client connections as they enter the network. Rate limiting > > in the Tor client itself would work better, but it's not a very stable > > equilibrium -- it encourages people to switch to security disasters > > like tortunnel. > > I talked to Nick about this idea, and he: > 1) Reminded me about proposal 163. Go read that thread. The main > difference is that I proposed a "or has a descriptor in its cache" > check too. > 2) Demanded that I break out the "is a client" to its own function. Ok. > 3) Thought it was a fine experiment to do. > > Here's the newer patch: > > http://archives.seul.org/or/cvs/Dec-2009/msg00390.html > > > My main concern here is that I wonder if we are being thorough enough at > > detecting "is a relay". It checks the consensus and the descriptor cache > > currently. So if the authorities think you're not Running, they won't put > > you in the consensus, and no relays will hear about you. If you go up and > > down, relays that serve dirport info will have your descriptor cached, > > so they'll recognize you so long as you were around in the past day or so. > > > > Relays that don't serve dirport info will stop fetching descriptors, > > but they'll continue to fetch the consensus. So they'll still mostly work. > > Soon I would like to make all relays above e.g. 50KB/s cache and serve > directory info. Having a separate open DirPort is becoming an obsolete > notion these days anyway now that most Tors use begindir requests over > the ORPort. Once we do that, these relays will be better at identifying > who else is a relay. I'd also like to make all relays regardless of their > dirport status answer begindir requests for their own descriptor. That bug > is currently preventing people (for example, me while testing censorship > stuff in Hong Kong) from using relays with no dirport set as bridges. Just wanted to let you know that this will change how we need to deal with weighting begindir requests. Right now the check done by clients is to verify dir_port != 0. This means that if we want clients to be able to easily adapt to new directory request weights yet still handle reweighting properly when everyone is a dir mirror, we need to signal this by specifying some magic dirport number in the consensus. That, or we need a different, yet backwards compatible flag in the check. V2Dir seems the wrong one, but it is all we have now. http://archives.seul.org/or/dev/Jan-2010/msg00019.html Thoughts? -- Mike Perry Mad Computer Scientist fscked.org evil labs
Attachment:
pgp6AkmQFPoh1.pgp
Description: PGP signature