There's no need to have a separate line conn-stats-end for the end date
and interval length with only a single line conn-bi-direct following.

Bugfix on 0.1.1.1-alpha; found by boboper.

Poet (Tim Sally) authored 14 years ago and Nick Mathewson committed 14 years ago

Specified grammars for orconn-status and entry-guards for Tor versions 0.1.2.2-alpha through 0.2.2.1-alpha with feature VERBOSE_NAMES turned off.

Poet (Tim Sally) authored 14 years ago and Nick Mathewson committed 14 years ago

The spec stated that support for the helper-nodes command would be removed
in 0.1.3.x, however support for this command is still in Tor. Updated the spec
to reflect this and added a node that the command is deprecated.

Poet (Tim Sally) authored 14 years ago and Nick Mathewson committed 14 years ago

Several updates to grammars for events and GETINFO results.  All relate
to the fact that LongName has replaced ServerID since 0.2.2.1-alpha. See
documentation of VERBOSE_NAMES for more information. The following
grammars were changed:
  * orconn-status GETINFO result
  * entry-guards GETINFO result
  * Path general token
  * OR Connection status changed event
  * New descriptors available event
In all cases a note was added about when the old grammar applies.

Poet (Tim Sally) authored 14 years ago and Nick Mathewson committed 14 years ago

(1) Made the wording of the comments consistant with token names.
Digest/Fingerprint and Name/Nickname were being used interchangeably.
Better to just use Fingerprint and Nickname becuase they are the names
of the tokens.

(2) Places the tokens currently in use before the tokens used in older
versions.  ServerSpec should be documented before ServerID.

(3) Added a note to the comments about ServerID that cross reference
the VERBOSE_FEATURE, allowing users to see when and why ServerID was
replaced with LongName.

Poet (Tim Sally) authored 14 years ago and Nick Mathewson committed 14 years ago

(1) On by default is a bad way to describe features. Rather, they
are always on and should be viewed as a part of the control
protocol. Updated the wording in USEFEATURE to reflect this.

(2) Made descriptions of Tor versions consistant across all
features. There is the version in which a feature was introduced and
the version in which it became part of the protocol.

(3) Reworded the description of the VERBOSE_NAMES feature. The
previous wording describes the way things used to be first. Better to
lead with the current state of things and then describe how it differs
from old versions.

Steven Murdoch authored 14 years ago and Nick Mathewson committed 14 years ago

This wasn't working due to the parameters of dup2 being in the wrong order.
As a result, tor-fw-helper was inheriting the stdin of Tor.

I don't know if any platforms we care about don't have FD_CLOEXEC,
but this is what we do elsewhere

NB: this will now register the socket with the socket accounting code

Conflicts:

	doc/Makefile.am

Conflicts:
	src/or/relay.c

This is not the most beautiful fix for this problem, but it is the simplest.

Bugfix for 2205.  Thanks to Sebastian and Mashael for finding the
bug, and boboper/cypherpunks for figuring out why it was happening
and how to fix it, and for writing a few fixes.

found via valgrind

Also add a changes file

On windows, it's called something different.

Mashael AlSabah authored 14 years ago and Nick Mathewson committed 14 years ago

 The reason the "streams problem" occurs is due to the complicated
interaction between Tor's congestion control and libevent. At some point
during the experiment, the circuit window is exhausted, which blocks all
edge streams. When a circuit level sendme is received at Exit, it
resumes edge reading by looping over linked list of edge streams, and
calling connection_start_reading() to inform libevent to resume reading.
When the streams are activated again, Tor gets the chance to service the
first three streams activated before the circuit window is exhausted
again, which causes all streams to be blocked again. As an experiment,
we reversed the order in which the streams are activated, and indeed the
first three streams, rather than the last three, got service, while the
others starved.

 Our solution is to change the order in which streams are activated. We
choose a random edge connection from the linked list, and then we
activate streams starting from that chosen stream. When we reach the end
of the list, then we continue from the head of the list until our chosen
stream (treating the linked list as a circular linked list). It would
probably be better to actually remember which streams have received
service recently, but this way is simple and effective.

Conflicts:
	configure.in
	contrib/tor-mingw.nsi.in
	src/win32/orconfig.h

Reported by an anonymous commenter on Trac.

Use S_CASE for ehostunreach, not E_CASE. Partial backport of 69deb22f. Fixes 0.2.1 compilation on windows