interim tweaks

svn:r9246
This commit is contained in:
Roger Dingledine 2007-01-03 03:45:53 +00:00
parent f72e82ccc4
commit 7396b8eecf
5 changed files with 16 additions and 15 deletions

View File

@ -1,4 +1,4 @@
Changes in version 0.1.2.5-xxxx - 200?-??-??
Changes in version 0.1.2.5-alpha - 2007-01-03
o Major features:
- Enable "BEGIN_DIR" cells: prefer to connect to the directory
server via TLS so we do encrypted directory requests rather than
@ -99,15 +99,16 @@ Changes in version 0.1.2.5-xxxx - 200?-??-??
schedule. Now the first connect attempt will wait a full 10
seconds before switching to a new circuit. Perhaps this will help
a lot. Based on observations from Mike Perry.
- Fix a bug on the Windows implementation of tor_mmap_file() that
would prevent the cached-routers file from ever loading (reported
by John Kimble).
o Minor bugfixes:
- Fix a bug when a PF socket is first used. (Patch from Fabian Keil.)
- Fix a bug when a BSD-style PF socket is first used. (Patch from
Fabian Keil.)
- Fix an assert failure when a directory authority sets
AuthDirRejectUnlisted and then receives a descriptor from an
unlisted router (reported by seeess).
- Fix a bug on the Windows implementation of tor_mmap_file that
would prevent the cached-routers file from ever loading (reported
by John Kimble).
- Fix a bug in 0.1.2.2-alpha that prevented clients from asking
to resolve an address at a given exit node even when they ask for
it by name.

View File

@ -78,7 +78,7 @@ $Id: /tor/branches/eventdns/doc/dir-spec.txt 9469 2006-11-01T23:56:30.179423Z ni
2.1. Vote specifications
Votes in v2.1 are just like v2 network status documents. We add these
Votes in v2.1 are similar to v2 network status documents. We add these
fields to the preamble:
"vote-status" -- the word "vote".

View File

@ -5,13 +5,13 @@ $Id$
Roger Dingledine
Nick Mathewson
Note: This document aims to specify Tor as implemented in 0.1.2.1-alpha-dev
Note: This document aims to specify Tor as implemented in 0.2.1.0-alpha-dev
and later. Future versions of Tor will implement improved protocols, and
compatibility is not guaranteed.
THIS DOCUMENT IS UNSTABLE. Right now, we're revising the protocol to remove
a few long-standing limitations. For the most stable current version of the
protocol, see tor-spec-v0.txt; current versions of Tor are backward-compatible.
protocol, see tor-spec.txt; current versions of Tor are backward-compatible.
This specification is not a design document; most design criteria
are not examined. For more information on why Tor acts as it does,
@ -271,7 +271,7 @@ TODO:
VERSIONS cells are used to introduce parameters and characteristics of
Tor clients and servers when connections are established.
4, Connection management
4. Connection management
Upon establishing a TLS connection, both parties immediately begin
negotiating a connection protocol version and other connection parameters.
@ -298,18 +298,18 @@ TODO:
a TLS connection has been established, the parties check whether the
other side has an obsolete certificate (organizationName equal to "Tor"
or "TOR"). If the other party presented an obsolete certificate,
we assume a v0 connection. Otherwise, both parties send VERSIONS
we assume a v1 connection. Otherwise, both parties send VERSIONS
cells listing all their supported versions. Upon receiving the
other party's VERSIONS cell, the implementation begins using the
highest-valued version common to both cells. If the first cell from
the other party is _not_ a VERSIONS cell, we assume a v0 protocol.
the other party is _not_ a VERSIONS cell, we assume a v1 protocol.
Implementations MUST discard cells that are not the first cells sent on a
connection.
4.2. MITM-prevention and time checking
If we negotiate a v1 connection or higher, the first cell we send SHOULD
If we negotiate a v2 connection or higher, the first cell we send SHOULD
be a NETINFO cell. Implementations SHOULD NOT send NETINFO cells at other
times.

View File

@ -109,7 +109,7 @@ authority for old-style (v1) directories as well. (Only directory mirrors
care about this.) Tor will use this server as an authority for hidden
service information if the "hs" flag is set, or if the "v1" flag is set and
the "no-hs" flag is \fBnot\fP set. If a flag "orport=\fBport\fR" is given,
Tor will consider use the given port to open encrypted tunnels to the
Tor will use the given port when opening encrypted tunnels to the
dirserver.
If no \fBdirserver\fP line is given, Tor will use the default
directory servers. NOTE: this option is intended
@ -964,7 +964,7 @@ A set of persistent key-value mappings. These are documented in the file. Thes
.LP
.TP
.B \fIDataDirectory\fP/bw_accounting
Used to track bandwidth accounting values (when the current period starts and ends; how much has been read and written so far this period). Soon to be obsoleted by state. Only used when bandwidth accounting is enabled.
Used to track bandwidth accounting values (when the current period starts and ends; how much has been read and written so far this period). This file is obsolete, and the data is now stored in the 'state' file as well. Only used when bandwidth accounting is enabled.
.LP
.TP
.B \fIDataDirectory\fP/control_auth_cookie

View File

@ -546,7 +546,7 @@ accounting_record_bandwidth_usage(time_t now, or_state_t *state)
uint64_t expected;
static time_t last_recorded;
/* First, update bw_accounting. Until 0.1.2.5-x, this was the only place
/* First, update bw_accounting. Until 0.1.2.5-alpha, this was the only place
* we stored this information. The format is:
* Version\nTime\nTime\nRead\nWrite\nSeconds\nExpected-Rate\n */