[or-cvs] r9240: Note more doable items; claim some; speculate more in dir-vo (in tor/trunk: . doc)
nickm at seul.org
nickm at seul.org
Tue Jan 2 20:08:07 UTC 2007
Author: nickm
Date: 2007-01-02 15:08:07 -0500 (Tue, 02 Jan 2007)
New Revision: 9240
Modified:
tor/trunk/
tor/trunk/doc/TODO
tor/trunk/doc/dir-voting.txt
Log:
r11788 at Kushana: nickm | 2007-01-02 14:41:45 -0500
Note more doable items; claim some; speculate more in dir-voting.txt
Property changes on: tor/trunk
___________________________________________________________________
svk:merge ticket from /tor/trunk [r11788] on c95137ef-5f19-0410-b913-86e773d04f59
Modified: tor/trunk/doc/TODO
===================================================================
--- tor/trunk/doc/TODO 2007-01-02 20:08:03 UTC (rev 9239)
+++ tor/trunk/doc/TODO 2007-01-02 20:08:07 UTC (rev 9240)
@@ -75,7 +75,6 @@
- Verify that it works well on windows
- Debug and re-enable server-side reverse DNS caching
-
- Critical but minor bugs, backport candidates.
- support dir 503s better
o clients don't log as loudly when they receive them
@@ -118,9 +117,12 @@
- More prominently, we should have a recommended apps list.
- recommend gaim.
- unrecommend IE because of ftp:// bug.
- - torrc.complete.in needs attention?
- - we should add a preamble to tor-design saying it's out of date.
- - Document transport and natdport
+N - torrc.complete.in needs attention?
+N - we should add a preamble to tor-design saying it's out of date.
+N - Document transport and natdport
+N - Look into generating torrc.{complete|sample}.in, tor.1.in,
+ the HTML manual, and the online config documentation from a single
+ source.
- Improvements to bandwidth counting
R - look into "uncounting" bytes spent on local connections, so
@@ -135,11 +137,15 @@
- Forward compatibility fixes
- Caches should start trying to cache consensus docs?
+NR - Design
+N - Implement, if we think it's smart.
- Start uploading short and long descriptors; authorities should support
URLs to retrieve long descriptors, and should discard short descriptors
for now. Later, once tools use the "long descriptor" URLs, authorities
will serve the short descriptors every time they're asked for
a descriptor.
+NR - Design
+N - Implement, if we think it's smart.
Topics to think about during 0.1.2.x development:
* Figure out incentives.
@@ -167,10 +173,6 @@
- What do we do about the fact that people can't read zlib-
compressed files manually?
- - Refactor DNS resolve implementation
- - Refactor exit side of resolve: do we need a connection_t?
- - Refactor entry side of resolve: do we need a connection_t?
-
- If the client's clock is too far in the past, it will drop (or
just not try to get) descriptors, so it'll never build circuits.
- Tolerate clock skew on bridge relays.
@@ -345,6 +347,10 @@
them) without having a corresponding client socket.
- Once this is done, it would be nice to have a way to request address
lookups from the controller without using SOCKS.
+ - Refactor exit/entry side of DNS resolve: we don't need a connection_t;
+ we can have an edge_connection_t and (say) dns_request_t both extend an
+ edge_stream_t, and have p_streams and n_streams both be linked lists
+ of edge_stream_t.
Future version:
- Configuration format really wants sections.
Modified: tor/trunk/doc/dir-voting.txt
===================================================================
--- tor/trunk/doc/dir-voting.txt 2007-01-02 20:08:03 UTC (rev 9239)
+++ tor/trunk/doc/dir-voting.txt 2007-01-02 20:08:07 UTC (rev 9240)
@@ -337,7 +337,8 @@
ever be used by anybody for routing. The long-form descriptor should be
used only for analytics and other tools. (If we allowed people to route with
long descriptors, we'd have to ensure that they stayed in sync with the
- short ones somehow.)
+ short ones somehow.) We can ensure that the short descriptors are used by
+ only recommending those in the network statuses.
Another possible solution would be to drop these fields from descriptors,
and have them uploaded as a part of a separate "bandwidth report" to the
@@ -349,20 +350,39 @@
3.5. Compression
Gzip would be easier to work with than zlib; bzip2 would result in smaller
- data lengths.
+ data lengths. [Concretely, we're looking at about 10-15% space savings at
+ the expense of 3-5x longer compression time for using bzip2.] Doing
+ on-the-fly gzip requires zlib 1.2 or later; doing bzip2 requires bzlib.
+ Pre-compressing status documents in multiple formats would force us to use
+ more memory to hold them.
4. Migration
For directory voting:
- * It would be cool if caches could get ready to download these, verify
- enough signatures, and serve them now. That way once stuff works all
- we need to do is upgrade the authorities. Caches don't need to verify
- the correctness of the format so long as it's signed.
+ * It would be cool if caches could get ready to download consensus
+ status docs, verify enough signatures, and serve them now. That way
+ once stuff works all we need to do is upgrade the authorities. Caches
+ don't need to verify the correctness of the format so long as it's
+ signed (or maybe multisigned?). We need to make sure that caches back
+ off very quickly from downloading consensus docs until they're
+ actually implemented.
For dropping the "opt" requirement:
- * stop requiring it as of 0.1.2.x. Stop generating it once earlier
- formats are obsolete.
+ * stopped requiring it as of 0.1.2.5-alpha. Stop generating it once
+ earlier formats are obsolete.
For multilevel keys:
* no idea
+ For long/short descriptors:
+ * In 0.1.2.x:
+ * Authorities should accept both, now, and silently drop short
+ descriptors.
+ * Routers should upload both once authorities accept them.
+ * There should be a "long descriptor" url and the current "normal" URL.
+ Authorities should serve long descriptors from both URLs.
+ * Once tools that want long descriptors support fetching them from the
+ "long descriptor" URL:
+ * Have authorities remember short descriptors, and serve them from the
+ 'normal' URL.
+
More information about the tor-commits
mailing list