cleanups based on looking through svn commits

      pointer loops.

    - Fix a memory leak when sending a 503 response for a networkstatus

      request.

    - If we're not marking exits as guards, ignore exit bandwidth

      when we're deciding the required bandwidth to become a guard.

    - If exits are rare enough that we're not marking exits as guards,

      ignore exit bandwidth when we're deciding the required bandwidth

      to become a guard.

    - When we're handling a directory connection tunneled over Tor,

      don't fill up internal memory buffers with all the data we want

      to tunnel; instead, only add it if the OR connection that will

      eventually receive it has some room for it. (This can lead to

      slowdowns in tunneled dir connections; a better solution will have

      to wait for 0.2.0.)

  o Minor bugfixes:

    - When computing clock skew from directory HTTP headers, consider what

      us from downloading a bunch of descriptors we don't need.

    - Do not log IPs with TLS failures for incoming TLS

      connections. (Fixes bug 382.)

    - When we're handling a directory connection tunneled over Tor,

      don't fill up internal memory buffers with all the data we want

      to tunnel; instead, only add it if the OR connection that will

      eventually receive it has some room for it. (This can lead to

      slowdowns in tunneled dir connections; a better solution will have

      to wait for 0.2.0.)

    - If the user asks to use invalid exit nodes, be willing to use the

      unstable ones.

    - Handle TTL values correctly on reverse DNS lookups.

  o Major features:

    - Weight directory requests by advertised bandwidth. Now we can

      let servers enable write limiting but still allow most clients to

      succeed at their directory requests.

      succeed at their directory requests. (We still ignore weights when

      choosing a directory authority; I hope this is a feature.)

  o Minor features:

    - Create a new file ReleaseNotes which was the old ChangeLog. The

      new ChangeLog file now includes the summaries for even development

      versions.

      new ChangeLog file now includes the summaries for all development

      versions too.

    - Check for addresses with invalid characters at the exit as well

      as at the client, and warn less verbosely when they fail. You can

      override this by setting ServerDNSAllowNonRFC953Addresses to 1.

  We use Guard nodes (also called "helper nodes" in the literature) to

  prevent certain profiling attacks.  Here's the risk: if we choose entry and

  exit nodes at random, and an attacker controls C out of N servers, then the

  exit nodes at random, and an attacker controls C out of N servers

  (ignoring advertised bandwidth), then the

  attacker will control the entry and exit node of any given circuit with

  probability (C/N)^2.  But as we make many different circuits over time,

  then the probability that the attacker will see a sample of about (C/N)^2

  A guard is unusable for a particular circuit if any of the rules for path

  selection in 2.2 are not met.  In particular, if the circuit is "fast"

  and the guard is not Fast, or if the circuit is "stable" and the guard is

  not Stable, Tor can't use the guard for that circuit.

  not Stable, or if the guard has already been chosen as the exit node in

  that circuit, Tor can't use it as a guard node for that circuit.

  If the guard is excluded because of its status in the networkstatuses for

  over 30 days, Tor removes it from the list entirely, preserving order.

  If Tor fails to connect to an otherwise usable guard, it retries

  periodically: every hour for six hours, every for hours for 3 days, every

  periodically: every hour for six hours, every 4 hours for 3 days, every

  18 hours for a week, and every 36 hours thereafter.  Additionally, Tor

  retries unreachable guards the first time it adds a new guard to the list,

  since it is possible that the old guards were only marked as unreachable

.LP

.TP

\fBBandwidthRate \fR\fIN\fR \fBbytes\fR|\fBKB\fR|\fBMB\fR|\fBGB\fR|\fBTB\fP

A token bucket limits the average bandwidth usage on this node to the

specified number of bytes per second. (Default: 3 MB)

A token bucket limits the average incoming bandwidth usage on this node

to the specified number of bytes per second, and the average outgoing

bandwidth usage to that same value. (Default: 3 MB)

.LP

.TP

\fBBandwidthBurst \fR\fIN\fR \fBbytes\fR|\fBKB\fR|\fBMB\fR|\fBGB\fR|\fBTB\fP

Limit the maximum token bucket size (also known as the burst) to the

given number of bytes. This value should be at least twice your

BandwidthRate. (Default: 6 MB)

given number of bytes in each direction. This value should be at least

twice your BandwidthRate. (Default: 6 MB)

.LP

.TP

\fBMaxAdvertisedBandwidth \fR\fIN\fR \fBbytes\fR|\fBKB\fR|\fBMB\fR|\fBGB\fR|\fBTB\fP

  info = tor_malloc_zero(sizeof(extend_info_t));

  strlcpy(info->nickname, s->nickname, sizeof(info->nickname));

  memcpy(info->identity_digest, s->identity_digest, DIGEST_LEN);

  info->onion_key = NULL; /* routerstatus doesn't include this! */

  info->onion_key = NULL; /* routerstatus doesn't know this */

  info->addr = s->addr;

  info->port = s->or_port;

  return info;

  return 0;

}

/** DOCDOC */

/** A high waterlevel for whether to refill this OR connection

 * with more directory information, if any is pending. */

#define BUF_FULLNESS_THRESHOLD (128*1024)

/** DOCDOC */

/** A bottom waterlevel for whether to refill this OR connection

 * with more directory information, if any is pending. We don't want

 * to make this too low, since we already run the risk of starving

 * the pending dir connections if the OR conn is frequently busy with

 * other things. */

#define BUF_EMPTINESS_THRESHOLD (96*1024)

/** Return true iff there is so much data waiting to be flushed on <b>conn</b>