diff options
author | Roger Dingledine <arma@torproject.org> | 2004-04-08 02:08:23 +0000 |
---|---|---|
committer | Roger Dingledine <arma@torproject.org> | 2004-04-08 02:08:23 +0000 |
commit | 190e59772a53fe9387a0055664648ddd9182948e (patch) | |
tree | aa18bbb65d5424fa81879789249726097a5058ae /doc/TODO | |
parent | 3f07083b0223008110e24bde1008bf6107ce7d8b (diff) | |
download | tor-190e59772a53fe9387a0055664648ddd9182948e.tar tor-190e59772a53fe9387a0055664648ddd9182948e.tar.gz |
more todo items marked off
svn:r1550
Diffstat (limited to 'doc/TODO')
-rw-r--r-- | doc/TODO | 7 |
1 files changed, 4 insertions, 3 deletions
@@ -138,13 +138,14 @@ Rendezvous service: o let bob choose himself as intro point o let bob replenish his intro points and republish o alice retries introduction and rendezvous a few times? - - should alice ever try to refresh her service desc cache entries? + o ORs should not pick themselves while building general circs + o should alice ever try to refresh her service desc cache entries? should she expire them after e.g. 15 mins? - - race condition: alice has the serverdesc in her cache, she opens + o race condition: alice has the serverdesc in her cache, she opens the circs, serverdesc expires and is flushed, then she goes to send the intro cell. should serverdesc cache have a last-touched field? are there better fixes? - - backward compatibility: when only certain nodes know about rend + o backward compatibility: when only certain nodes know about rend protocol, how do we deal? have nodes parse the tor version field? force an upgrade? simply be more robust against useless nodes? o should expire rend streams when too much time has passed |