Solving all the bugs that were their when I arrived this morning.
[re6stnet.git] / TODO
1 To be done :
2     Add options to start udp server, tcp server or both
3
4     use the server as a bootstrap node
5
6     Use an algorithm to choose which connections to keep and/or establish
7     instead of pure randomness
8
9     Find a name for the project : the projet is ( or should be ) independant
10     from vifib, openvpn, babel, and so should the name; btw we aim to build a
11     distributed, scalable, resilient VPN.... ( if it helps with the name )
12
13     Replace comments at the beginning of functions with docstrings & give all
14     fn docstrings
15
16     Use the server events ( client connection/deconnection ) to do something
17     useful
18
19     In peers DB, flag the dead peers so we only choose them if necessary and we can remove them if we have enought peers
20
21     Use a timeout for the server peersDB so we can rflag unreachable peers and
22     remove the peers whose certificate is no longer valid
23
24     Specify a lease duration in ForwardViaUPnP
25
26     Handle LAN internally in order not to have catastrophic results ....
27
28 To be discussed:
29     G : Database structure for bith vifibnet and registry have been changed.
30         Index is now always on the prefix ( there is no id anymore ). And
31         the (ip, port, proto) tuples have been replaced with addresses :
32         it is a list of ip, port, proto, that way a peer can announce
33         different (port, proto) combination.
34
35     G, J : To get traffic stats ( bytes in/out ), you can use
36           /sys/class/net/interface/statistics/rx_bytes, etc...
37         or /proc/net/dev/snmp6/interface ( all in one file ). This can be enough
38         if used as follows: get traffic diff from last time we checked in order
39         to choose which connection is significantly unused compared to others,
40         and close it. Of course, too recent connections (i.e. those for which we
41         have no previous stat) would be always kept.
42         This should be combined with routing table (i.e. how many nodes are
43         served by each tunnel), which is possibly redundant.
44         ip6tables should be avoided if possible.
45     U : Great !!!
46
47     U : Babel seems to be very long to establish the routes : maybe we should
48         tell him thant we are not on a wired network but on a mobile network ?
49     G : babel establish routes quickly enough i'd say. There are two new
50         options : hello and wireless, for hello_interval and treating all
51         interfaces as wireless. However, treating an interface as wireless
52         doesn't lessen the hello_interval, it only changes how babel estimates
53         quality link, and cost.
54     U : from babel web page : "When the Babel daemon detects a wired network,
55         it will use a larger interval between hellos".
56         Moreover, it seems that the wireless option only means
57         "hostile environment" which seems best for a resilient network.
58         30 sec of hello interval seams also too much. The default value for
59         babel is 4 sec (from babel man page).
60         According to raphael's stats on the nexedi's server downtime,
61         45% of the problems dont last more than 2 minutes, 55% no more than
62         3 minutes If it takes 2 min to detect a dead connection, then we wont be
63         solving many problems with our overlay network
64
65     U : The peer DB size should depend on the number of connection and the
66         refresh time
67     G : ?! I don't agree, the db size should be proportional ( with a factor
68         like 0.01 or less ) to the total number of peers in the entire network,
69         with maybe a max size.
70     U : what we need to do  is to keep the randomness. For this, we need a big
71         enought DB to ensure we can still choose a peer as if it was choosen
72         directly from the server. The requiered db size can be calculated from
73         the number of connections and the refresh time.
74
75     U : Why are --ip and internal-port mutually exclusive ?
76         Currently upnp only forward via UDP. Should he also forward via TCP ?
77         Why dont we only use UDP ?
78         No error should be raised when no upnp is detected : we should allow
79         machines having public IP to do an automatic configuration using the
80         discovery by an other peer