[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r10749: Added GSoC-status document (torflow/trunk)
Date: 2007-07-06 07:53:55 -0400 (Fri, 06 Jul 2007)
New Revision: 10749
Added GSoC-status document
--- 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?