Implement proposal 109: As an authority, never call more than 3 servers per IP Running and Valid. Prefer Running servers to non-running ones; then prefer high-bandwidth to low-bandwidth. Needs testing.
svn:r10968
Make our control events for multi-line async replies conform to our old grammar. Change back to the old grammar (which got "corrected" in r10931).
svn:r10964
ADDRMAP events should never have specified local time. Extend them to have the proper gmt time, and make GETINFO address-mappings always do the right thing (since it is new in this version).
svn:r10930
at least 100KB/s, and consider their bandwidth adequate to be a
Guard if it is at least 250KB/s. This fix complements proposal
107. [Bugfix on 0.1.2.x]
svn:r10897
- demand options->Bridges and options->TunnelDirConns if
options->UseBridges is set.
- after directory fetches, accept descriptors that aren't referenced by
our networkstatuses, *if* they're for a configured bridge.
- delay directory fetching until we have at least one bridge descriptor.
- learn how to build a one-hop circuit when we have neither routerinfo
nor routerstatus for our destination.
- teach directory connections how to pick a bridge as the destination
directory when doing non-anonymous fetches.
- tolerate directory commands for which the dir_port is 0.
- remember descriptors when the requested_resource was "authority",
rather than just ignoring them.
- put bridges on our entry_guards list once we have a descriptor for them.
When UseBridges is set, only pick entry guards that are bridges. Else
vice versa.
svn:r10571
"Who will enable this option?" section towards the top of the proposal, to
attempt to get everyone on the same page right away as far as assumptions
go.
Also, added section on "Consideration of risks for node operators" where
the additional risk of should-be-3-but-actually-2 hop users pose to node
operators is discussed. Upon consideration of this, determined that two hop
users should be made to rotate guards with some frequency on the order of
days (basically, long enough to help scan the network for active adversary
guards, and then move on).
Please re-flame if you feel these or other issues have not been adequately
addressed.
svn:r10498
Adapt code to parse v3 networkstatus votes so it can also parse a consensus. Make networkstatus_vote_t the catch-all type for votes and conensuses. Correct/clarify the second argument to directory-signature.
svn:r10491
reliable and not rotate as much for dialup, mobile, or transient network
users, and what if users were actually notified more visibly who their guards
were and came to trust the guard nodes they have? Some effects of this are
considered.
svn:r10470
