In simulation : we can now see the effects of the tunnel manager
[re6stnet.git] / TODO
1 To be done :
2     Upgrade the logging function in order to be able to log message like
3     "Refreshing peers DB ... done", or add log messages to specify that an
4     action advertised by a previous log message has been completed
5
6     use the server as a bootstrap node -> switch peer discovery to be done
7     by vifibnet directly ?
8
9     Use an algorithm to choose which connections to keep and/or establish
10     instead of pure randomness
11         |-> number of routes / tunnel : doesn't work
12         |-> favorise most used roads ?
13
14     Find a name for the project : the projet is ( or should be ) independant
15     from vifib, openvpn, babel, and so should the name; btw we aim to build a
16     distributed, scalable, resilient VPN.... ( if it helps with the name )
17
18     Replace comments at the beginning of functions with docstrings & give all
19     fn docstrings
20
21     In peers DB, flag the dead peers so we only choose them if necessary and we
22     can remove them if we have enought peers
23
24     Use a timeout for the server peersDB so we can flag unreachable peers and
25     remove the peers whose certificate is no longer valid
26
27     Specify a lease duration in ForwardViaUPnP and also forward a tcp port
28
29     Handle LAN internally in order not to have catastrophic results ....
30     ( avahi could be used )
31
32 To be discussed:
33     U : Babel seems to be very long to establish the routes : maybe we should
34         tell him thant we are not on a wired network but on a mobile network ?
35     G : babel establish routes quickly enough i'd say. There are two new
36         options : hello and wireless, for hello_interval and treating all
37         interfaces as wireless. However, treating an interface as wireless
38         doesn't lessen the hello_interval, it only changes how babel estimates
39         quality link, and cost.
40     U : from babel web page : "When the Babel daemon detects a wired network,
41         it will use a larger interval between hellos".
42         Moreover, it seems that the wireless option only means
43         "hostile environment" which seems best for a resilient network.
44         30 sec of hello interval seams also too much. The default value for
45         babel is 4 sec (from babel man page).
46         According to raphael's stats on the nexedi's server downtime,
47         45% of the problems dont last more than 2 minutes, 55% no more than
48         3 minutes If it takes 2 min to detect a dead connection, then we wont be
49         solving many problems with our overlay network
50     G : ok, so babel hello-interval should be set to a lower value,
51         we should do some tests to pinpoint the best compromise between
52         speed and bandwith usage.
53         Btw, is there a doc ( pdf, image, file ) resuming Raphael's stats
54         on nexedi's server downtime ? it could be useful for the internship
55         rapport
56
57     G : I think the number of route going through an interface should be a
58         Connection attribute, not a dict in tunnelManager
59     U : Yes, it was planned, just wait for me to finish implementing it
60
61     U :  '--up', 'ovpn-server %s/%u' % (server_ip, len(network)) in plib.py
62         if you use len(network), this means that all our network is on the 
63         same LAN and that the interface of the server is connected to it
64         wich means that any packet should be routed to this interface
65         an interface should only advertise the /64 (or less) which has been 
66         attributed to it