TODO again
[re6stnet.git] / TODO
1 For Ulysse : useful is spelled with only ONE l and not two.....
2             + ALL files should now respect a maximum 80 rows convention
3
4 Bugs :
5     When no peer is avalaible, the setup crash without the --no-boot option
6     => see below
7
8 To be done :
9     Use an algorithm to choose which connections to keep and/or establish
10     instead of pure randomness
11     Find a name for the project : the projet is ( or should be ) independant
12     from vifib, openvpn, babel, and so should the name; btw we aim to build a
13     distributed, scalable, resilient VPN.... ( if it helps with the name )
14     Replace comments at the beginning of functions with docstrings & give all
15     fn docstrings
16     Use the server events ( client connection/deconnection ) to do something
17     useful
18     In peers DB, remove some peers when they are too many of them -> remove the
19     dead peers
20     Use a timeout for the peersDB -> ?, removing the dead peers should be enough
21     Specify a lease duration in ForwardViaUPnP
22     Handle LAN internally in order not to have catastrophic results ....
23
24 To be discussed:
25     G, J : To get traffic stats ( bytes in/out ), you can use
26           /sys/class/net/interface/statistics/rx_bytes, etc...
27         or /proc/net/dev/snmp6/interface ( all in one file ). This can be enough
28         if used as follows: get traffic diff from last time we checked in order
29         to choose which connection is significantly unused compared to others,
30         and close it. Of course, too recent connections (i.e. those for which we
31         have no previous stat) would be always kept.
32         This should be combined with routing table (i.e. how many nodes are
33         served by each tunnel), which is possibly redundant.
34         ip6tables should be avoided if possible.
35
36     U : Babel seems to be very long to establish the routes : maybe we should
37         tell him thant we are not on a wired network but on a mobile network ?
38     G : babel establish routes quickly enough i'd say. There are two new
39         options : hello and wireless, for hello_interval and treating all
40         interfaces as wireless. However, treating an interface as wireless
41         doesn't lessen the hello_interval, it only changes how babel estimates
42         quality link, and cost.
43
44     U : Contact the server using vifibnet and not the underlying network when
45         possible
46     G : done by giving the vifibnet address of the server. Anyways, if you give
47         the 'internet' address of the server, it CANNOT be reached via vifib,
48         as there isn't yet a border vpn through which the internet traffic
49         would be routed
50
51     U : The peer DB size should depend on the number of connection and the
52         refresh time
53     G : ?! I don't agree, the db size should be proportional ( with a factor
54         like 0.01 or less ) to the total number of peers in the entire network,
55         with maybe a max size.
56
57     U : Remove the --no-boot option since we know when no node is avalaible
58     G : the no-boot option is only useful when the server knows no peer,
59         irl it should never happen, no-boot is a debug option
60     U : Ok, but the server knows when no peers is avalaible, doesn't he ?
61     G : Well when no peer is available the SQL request ( + next() method ) raise
62         a StopIteration exception
63
64     G : don't reconnect to server each time we repopulate in peers_db ?
65     U : From what I've read on the internet, when you create a server object,
66         you don't connect to the server, You only connect to the server once you
67         send a request for a methode and then you can automatically use the same
68         connection for 15sec
69     G : ok, it justs need testing ( for when some requests for the server will
70         require to be plugged in the network )
71
72     U : Use more than one boostrap node
73     G : we'll use the server as a bootstrap node