[or-cvs] Describe approach to downloading status documents; update T...

[nickm@xxxxxxxx (Nick Mathewson)]

Update of /home/or/cvsroot/tor/doc
In directory moria:/tmp/cvs-serv11019/doc

Modified Files:
	TODO dir-spec.txt 
Log Message:
Describe approach to downloading status documents; update TODO a bit

Index: TODO
===================================================================
RCS file: /home/or/cvsroot/tor/doc/TODO,v
retrieving revision 1.346
retrieving revision 1.347
diff -u -d -r1.346 -r1.347
--- TODO	27 Aug 2005 03:20:51 -0000	1.346
+++ TODO	2 Sep 2005 20:46:44 -0000	1.347
@@ -115,9 +115,10 @@
       - find 10 dirservers.
         - (what are criteria to be a dirserver?)
 N     . Dirservers publish compressed network-status objects.
-        - Support several-at-once
+        - Support retrieving several-at-once
 N     . Everyone downloads network-status objects
         - From all directories, round-robin
+        . Parse them
         - Cache them, reload on restart
         o Serve cached directories
 N     . Directories expose individual descriptors
@@ -152,6 +153,8 @@
   - Start using create-fast cells as clients
   o Let more config options (e.g. ORPort) change dynamically.
   - start handling server descriptors without a socksport?
+  o Add TTLs to DNS-related replies, and use them (where present) to adjust
+    addressmap values.
 
   . Research memory use on Linux: what's happening?
     - Is it threading?  (Maybe, maybe not)

Index: dir-spec.txt
===================================================================
RCS file: /home/or/cvsroot/tor/doc/dir-spec.txt,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -d -r1.12 -r1.13
--- dir-spec.txt	2 Sep 2005 20:28:29 -0000	1.12
+++ dir-spec.txt	2 Sep 2005 20:46:44 -0000	1.13
@@ -228,7 +228,26 @@
 
    Clients store network status documents so long as they are live.
 
-5.1. Managing naming
+5.1. Scheduling network status downloads
+
+   This download scheduling algorithm implements the approach described above
+   in a relatively low-state fashion.  It reflects the current Tor
+   implementation.
+
+   Clients maintain a list of authorities; each client tries to keep the same
+   list, in the same order.
+
+   Periodically, on startup, and on HUP, clients check whether they need to
+   download fresh network status documents.  The approach is as follows:
+     - If we have under X network status documents newer than OLD, we choose a
+       member of the list at random and try download XX documents starting
+       with that member's.
+     - Otherwise, if we have no network status documents newer than NEW, we
+       check to see which authority's document we retrieved most recently,
+       and try to retrieve the next authority's document.  If we can't, we
+       try the next authority in sequence, and so on.
+
+5.2. Managing naming
 
    In order to provide human-memorable names for individual server
    identities, some directory servers bind names to IDs.  Clients handle