[or-cvs] r10749: Added GSoC-status document (torflow/trunk)

[renner at seul.org]

Author: renner
Date: 2007-07-06 07:53:55 -0400 (Fri, 06 Jul 2007)
New Revision: 10749

Added:
   torflow/trunk/GSoC-status
Log:

  Added GSoC-status document



Added: torflow/trunk/GSoC-status
===================================================================
--- torflow/trunk/GSoC-status	                        (rev 0)
+++ torflow/trunk/GSoC-status	2007-07-06 11:53:55 UTC (rev 10749)
@@ -0,0 +1,76 @@
+General things I already did:
+
+- Extended TorCtl.py to be able to specify the 'hop' when attaching streams
+- Extended the Router class for country_code and continent and sat up a
+  country-to-continent mapping for that
+- Created a class GeoIPConfig for the configuration and extended the
+  SelectionManager to add the necessary restrictions
+- Implemented Node/PathRestrictions: CountryCode, UniqueCountry, SingleCountry,
+  ExcludeCountries, ContinentCrossings, ContinentJumper, UniqueContinent
+- Created a separate CircuitHandler that can maintain a pool of n circuits
+  and the StreamHandler for attaching streams
+
+My controller (op-addon.py) is currently able to:
+
+- Create and maintain a pool of n circuits and configure the path selection
+  freely + attach user streams
+- Optionally Ping the circuits in the pool with a configurable frequency
+- Close those circuits that are too slow regarding measured latencies:
+  circ was in x measurings slower than y seconds --> close it
+- Attach user streams to the circuit having the currently smallest rt-latency
+- Optionally ping every circuit n ( = hop-count) times using each single hop 
+  as the exit node once
+- Compute round-trip latencies for the single links between routers from the 
+  results and store everything in a graph model
+- Create circuits from the network model, so we will create known to be fast 
+  ones possibly again or if we have collected enough data we will find new 
+  fast combinations of links to put together to circuits we have not had yet
+- Choose randomly from a set of at least x circuit proposals found in the 
+  model, each having RTT < y ms
+- If we could not find x proposals: create a circuit with the default method 
+  for collecting more link-latencies
+- Be configured to always have m/n of the circuits created with the default 
+  method to steadily extend the graph model
+- Collect data and record mean round trip latencies (of n measurings on each 
+  circuit) for a specific path selection configuration to a file
+- Record statistics about circuit creation to a file: average setup duration +
+  min/max/median, number of failures + single extend-times
+
+Things I currently plan to do are:
+
+- Implement more PathRestrictions: OceanPhobic/OceanPhilic, EchelonPhobic for 
+  changing destinations, which means querying the country of a destination on 
+  set_target() and adding the respective CountryRestriction to exit_rstr 
+  before building the circ.
+- Use a config file .pathrc for all of the configuration options
+- Somehow validate a given configuration (e.g. entry_country:DE, 
+  exit_country:US, max_crossings:0 would be invalid)
+- Or as a first step: give an informative error and a hint to change the 
+  configuration in case of the NoRouters exception
+- Implement the BwWeightedGenerator
+- Refactorings: Move CircuitHandler and StreamHandler to PathSupport.py or 
+  create a new separate file containing only the EventHandlers (so that they 
+  can also be used by metatroller or other controllers)?
+- Refactorings: Transfer other things to PathSupport.py to be permanent, like 
+  'hop' as an attribute to the Stream-class
+- Add port history learning to StreamHandler or CircuitHandler and 
+  port-preconfiguring: the ability to configure that we will need circuits 
+  that exit e.g. to port x, y and z
+- Add an option to op-addon to tell it to use every path only once and create 
+  only *really* new circuits (combinations of links) from the model
+- Needs a path-history and more data collecting, but leads to more security?
+- Keep on using a directed graph for the model (undirected would make it more 
+  difficult to find new circuits means needs more collecting)?
+- What is a beneficial network model and how long does it take to learn one?
+- Modify op-addon.py to be able to connect to hidden services? 
+  Is that actually possible?
+- Evaluate and compare different path selection configurations 
+- Degree of anonymity?
+- Test all of the code again and again
+- Introduce recordings of more statistics
+- Find a better name than 'op-addon.py'?
+- Write a README containing prerequisites and instructions to run op-addon.py
+- Remove bw-informer.py from the svn or improve it or do something else using 
+  bandwidth (my supervisor Andriy keeps on telling me to)
+- Maybe test complete circuits once for bandwidth by transferring something
+  like speedracer does and rank the circuits for measured bandwidths?