Added some comments in the TODO file
[re6stnet.git] / TODO
1 Bugs :
2     When no peer is avalaible, the setup crash without the --no-boot option
3     G : see below
4     U : this is still a bug to be solved
5
6 To be done :
7     Use an algorithm to choose which connections to keep and/or establish
8     instead of pure randomness
9     
10     Find a name for the project : the projet is ( or should be ) independant
11     from vifib, openvpn, babel, and so should the name; btw we aim to build a
12     distributed, scalable, resilient VPN.... ( if it helps with the name )
13     
14     Replace comments at the beginning of functions with docstrings & give all
15     fn docstrings
16     
17     Use the server events ( client connection/deconnection ) to do something
18     useful
19     
20     In peers DB, remove some peers when they are too many of them -> remove the
21     dead peers
22     
23     Use a timeout for the peersDB 
24     G : removing the dead peers should be enough
25     U : I was speaking of the server peers DB
26     
27     Specify a lease duration in ForwardViaUPnP
28     
29     Handle LAN internally in order not to have catastrophic results ....
30
31 To be discussed:
32     G, J : To get traffic stats ( bytes in/out ), you can use
33           /sys/class/net/interface/statistics/rx_bytes, etc...
34         or /proc/net/dev/snmp6/interface ( all in one file ). This can be enough
35         if used as follows: get traffic diff from last time we checked in order
36         to choose which connection is significantly unused compared to others,
37         and close it. Of course, too recent connections (i.e. those for which we
38         have no previous stat) would be always kept.
39         This should be combined with routing table (i.e. how many nodes are
40         served by each tunnel), which is possibly redundant.
41         ip6tables should be avoided if possible.
42     U : Great !!!
43
44     U : Babel seems to be very long to establish the routes : maybe we should
45         tell him thant we are not on a wired network but on a mobile network ?
46     G : babel establish routes quickly enough i'd say. There are two new
47         options : hello and wireless, for hello_interval and treating all
48         interfaces as wireless. However, treating an interface as wireless
49         doesn't lessen the hello_interval, it only changes how babel estimates
50         quality link, and cost.
51     U : from babel web page : "When the Babel daemon detects a wired network, 
52         it will use a larger interval between hellos".
53         Moreover, it seems that the wireless option only means 
54         "hostile environment" which seems best for a resilient network. 
55         30 sec of hello interval seams also too much. The default value for
56         babel is 4 sec (from babel man page).
57         According to raphael's stats on the nexedi's server downtime, 
58         most of the problems dont last more than 3 min. If it takes 2 min to 
59         detect a dead connection, then we wont be solving anything with our 
60         overlay network
61         Thimothée is making some stats about this for his internship. I will 
62         commit them as soon as he as finished
63
64     U : The peer DB size should depend on the number of connection and the
65         refresh time
66     G : ?! I don't agree, the db size should be proportional ( with a factor
67         like 0.01 or less ) to the total number of peers in the entire network,
68         with maybe a max size.
69     U : what we need to do  is to keep the randomness. For this, we need a big
70         enought DB to ensure we can still choose a peer as if it was choosen 
71         directly from the server. The requiered db size can be calculated from
72         the number of connections and the refresh time.
73
74     U : Remove the --no-boot option since we know when no node is avalaible
75     G : the no-boot option is only useful when the server knows no peer,
76         irl it should never happen, no-boot is a debug option
77     U : Ok, but the server knows when no peers is avalaible, doesn't he ?
78     G : Well when no peer is available the SQL request ( + next() method ) raise
79         a StopIteration exception
80     U : Well, I don't think this is a good thing. When not in debug, a node 
81         cannot now if their is anyone else already connected
82
83     G : don't reconnect to server each time we repopulate in peers_db ?
84     U : From what I've read on the internet, when you create a server object,
85         you don't connect to the server, You only connect to the server once you
86         send a request for a methode and then you can automatically use the same
87         connection for 15sec
88     G : ok, it justs need testing ( for when some requests for the server will
89         require to be plugged in the network )
90
91     U : Use more than one boostrap node
92     G : we'll use the server as a bootstrap node