Spec changes for proposal 181 (client-side optimistic data)

This commit is contained in:
Nick Mathewson 2011-07-20 11:08:09 -04:00
parent 6a2136dac7
commit 4212db3cb9
4 changed files with 22 additions and 3 deletions

View File

@ -1207,6 +1207,11 @@
parameters governing behavior" in path-spec.txt for a series of
circuit build time related consensus params.
"UseOptimisticData" -- If set to zero, clients by default
shouldn't try to send optimistic data to servers until they have
received a RELAY_CONNECTED cell.
Min: 0, Max: 1
The authority section of a vote contains the following items, followed
in turn by the authority's current key certificate:

View File

@ -101,7 +101,7 @@ Proposals by number:
178 Require majority of authorities to vote for consensus parameters [OPEN]
179 TLS certificate and parameter normalization [DRAFT]
180 Pluggable transports for circumvention [OPEN]
181 Optimistic Data for Tor: Client Side [OPEN]
181 Optimistic Data for Tor: Client Side [CLOSED]
182 Credit Bucket [DRAFT]
@ -133,7 +133,6 @@ Proposals by status:
177 Abstaining from votes on individual flags [for 0.2.3.x]
178 Require majority of authorities to vote for consensus parameters [for 0.2.3.x]
180 Pluggable transports for circumvention [for 0.2.3.x]
181 Optimistic Data for Tor: Client Side
ACCEPTED:
110 Avoiding infinite length circuits [for 0.2.3.x] [in 0.2.1.3-alpha]
117 IPv6 exits [for 0.2.3.x]
@ -186,6 +185,7 @@ Proposals by status:
167 Vote on network parameters in consensus [in 0.2.2]
171 Separate streams across circuits by connection metadata [in 0.2.3.3-alpha]
174 Optimistic Data for Tor: Server Side [in 0.2.3.1-alpha]
181 Optimistic Data for Tor: Client Side [in 0.2.3.3-alpha]
SUPERSEDED:
112 Bring Back Pathlen Coin Weight
113 Simplifying directory authority administration

View File

@ -2,7 +2,8 @@ Filename: 181-optimistic-data-client.txt
Title: Optimistic Data for Tor: Client Side
Author: Ian Goldberg
Created: 2-Jun-2011
Status: Open
Status: Closed
Implemented-In: 0.2.3.3-alpha
Overview:

View File

@ -75,6 +75,19 @@ Tor's extensions to the SOCKS protocol
misconfigured. This is helpful for the many users who mistakenly try to
use Tor as an HTTP proxy instead of a SOCKS proxy.
5. Optimistic data
Tor allows SOCKS clients to send connection data before Tor has sent a
SOCKS response. When using an exit node that supports "optimistic data",
Tor will send such data to the server without waiting to see whether the
connection attempt succeeds. This behavior can save a single round-trip
time when starting connections with a protocol where the client speaks
first (like HTTP). Clients that do this must be ready to hear that
their connection has succeeded or failed _after_ they have sent the
data.
References:
[1] http://archive.socks.permeo.com/protocol/socks4.protocol
[2] http://archive.socks.permeo.com/protocol/socks4a.protocol