[or-cvs] Commit fixes for several pending tor core tasks: document a...

[nickm@xxxxxxxx (Nick Mathewson)]

Update of /home/or/cvsroot/tor/doc
In directory moria.mit.edu:/tmp/cvs-serv21573/doc

Modified Files:
	TODO control-spec.txt tor.1.in 
Log Message:
Commit fixes for several pending tor core tasks: document all DOCDOCed functions; time out uncontrolled unattached streams; feed reasons to SOCKS5 (refactoring connection_ap_handshake_socks_reply in the process); change DirFetchPeriod/StatusFetchPeriod to have a special "Be smart" value.

Index: TODO
===================================================================
RCS file: /home/or/cvsroot/tor/doc/TODO,v
retrieving revision 1.279
retrieving revision 1.280
diff -u -d -r1.279 -r1.280
--- TODO	14 Mar 2005 03:12:59 -0000	1.279
+++ TODO	17 Mar 2005 12:38:35 -0000	1.280
@@ -38,7 +38,9 @@
          o Implement patch, if so.
          - Implement Tor side once patch is accepted.
        o Check return from event_set, event_add, event_del.
-       - Keep pushing to get a windows patch accepted.
+       o Keep pushing to get a windows patch accepted.
+       - After about 26 March, check back with Niels; he should be back
+         by then.
 
  Security:
    - Make sure logged info is "safe"ish.
@@ -72,13 +74,13 @@
     - EXTENDCIRCUIT
 R     - revised circ selection stuff.
       - Implement controller interface.
-    . ATTACHSTREAM
+    o ATTACHSTREAM
       o Make streams have an 'unattached and not-automatically-attachable'
         state. ("Controller managed.")
       o Add support to put new streams into this state rather than try to
         attach them automatically.  ("Hidden" config option.)
       o Implement 'attach stream X to circuit Y' logic.
-      - Time out never-attached streams.
+      o Time out never-attached streams.
       o If we never get a CONNECTED back, we should put the stream back in
         CONTROLLER_WAIT, not in CIRCUIT_WAIT.
     - Tests for new controller features
@@ -101,9 +103,9 @@
       (Turns out, if package_raw_inbuf fails, it *can't* send an end cell.)
     o Check for any place where we can close an edge connection without
       sending an end; see if we should send an end.
-N . Feed end reason back into SOCK5 as reasonable.
+  o Feed end reason back into SOCK5 as reasonable.
 R o cache .foo.exit names better, or differently, or not.
-N - make !advertised_server_mode() ORs fetch dirs less often.
+  o make !advertised_server_mode() ORs fetch dirs less often.
 N - Clean up NT service code even more.  Document it. Enable it by default.
     Make sure it works.
 

Index: control-spec.txt
===================================================================
RCS file: /home/or/cvsroot/tor/doc/control-spec.txt,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -d -r1.22 -r1.23
--- control-spec.txt	14 Mar 2005 22:15:45 -0000	1.22
+++ control-spec.txt	17 Mar 2005 12:38:35 -0000	1.23
@@ -346,8 +346,6 @@
 
 3.15 ATTACHSTREAM (Type 0x000E)
 
-  [Proposal; not finalized]
-
   Sent from the client to the server.  The message body contains two fields:
       Stream ID [4 octets]
       Circuit ID [4 octets]
@@ -367,8 +365,6 @@
 
 3.16 POSTDESCRIPTOR (Type 0x000F)
 
-  [Proposal; not finalized]
-
   Sent from the client to the server.  The message body contains one field:
       Descriptor [NUL-terminated string]
 
@@ -383,10 +379,8 @@
 
 3.17 FRAGMENTHEADER (Type 0x0010)
 
-  [Proposal; not finalized]
-
   Sent in either direction.  Used to encapsulate messages longer than 65535
-  bytes long.
+  bytes in length.
 
       Underlying type [2 bytes]
       Total Length    [4 bytes]
@@ -403,10 +397,12 @@
 
 3.18 FRAGMENT (Type 0x0011)
 
-  [Proposal; not finalized]
-
       Data           [Entire message]
 
+  See FRAGMENTHEADER for more information
+
+3.19 
+
 4. Implementation notes
 
 4.1. There are four ways we could authenticate, for now:

Index: tor.1.in
===================================================================
RCS file: /home/or/cvsroot/tor/doc/tor.1.in,v
retrieving revision 1.62
retrieving revision 1.63
diff -u -d -r1.62 -r1.63
--- tor.1.in	12 Mar 2005 20:18:38 -0000	1.62
+++ tor.1.in	17 Mar 2005 12:38:35 -0000	1.63
@@ -114,11 +114,14 @@
 \fBDirFetchPeriod \fR\fIN\fR \fBseconds\fR|\fBminutes\fR|\fBhours\fR|\fBdays\fR|\fBweeks\fP
 Every time the specified period elapses, Tor downloads a directory.
 A directory contains a signed list of all known servers as well as
-their current liveness status.  (Default: 1 hour)
+their current liveness status. A value of "0 seconds" tells Tor to choose an
+appropriate default. (Default: 1 hour for clients, 20 minutes for servers.)
 .TP
-\fBStatusFetchPeriod \fR\fIN\fR \fBseconds\fR|\fBminutes\fR|\fBhours\fR|\fBdays\fR|\fBweeks\fP
-Every time the specified period elapses, Tor downloads signed status
-information about the current state of known servers.  (Default: 20 minutes.)
+\fBStatusFetchPeriod \fR\fIN\fR \fBseconds\fR|\fBminutes\fR|\fBhours\fR|\fBdays\fR|\fBweeks\fP Every time the
+specified period elapses, Tor downloads signed status information about the
+current state of known servers.  A value of "0 seconds" tells Tor to choose
+an appropriate default. (Default: 30 minutes for clients, 15 minutes for
+servers.)  (Default: 20 minutes.)
 .TP
 \fBRendPostPeriod \fR\fIN\fR \fBseconds\fR|\fBminutes\fR|\fBhours\fR|\fBdays\fR|\fBweeks\fP
 Every time the specified period elapses, Tor uploads any rendezvous