TODO updated
[re6stnet.git] / TODO
1 For Ulysse : useful is spelled with only ONE l and not two.....
2
3 Bugs :
4     When no peer is avalaible, the setup crash without the --no-boot option => see below
5
6 To be done :
7    Use an algorithm to choose which connections to keep and/or establish instead or pure randomness
8     Find a name for the project : the projet is ( or should be ) independant from vifib, openvpn, babel,
9          and so should the name; btw we aim to build a distributed, scalable, resilient VPN....
10     Replace comments at the beginning of functions with docstrings & give all fn docstrings
11     Use the server events ( client connection/deconnection ) to do something useful
12     In peers DB, remove some peers when they are too many of them -> remove the dead peers
13     Use a timeout for the peersDB -> ?, removing the dead peers should be enough
14     Specify a lease duration in ForwardViaUPnP
15
16 To be discussed:
17     U : Babel seems to be very long to establish the routes : maybe we should tell him thant we are not on a wired network but on a mobile network ?
18     G : babel establish routes quickly enough i'd say. There are two new options : hello and wireless, for hello_interval and
19         treating all interfaces as wireless. However, treating an interface as wireless doesn't lessen the hello_interval, it only
20         changes how babel estimates quality link, and cost.
21
22     U : Contact the server using vifibnet and not the underlying network when possible
23     G : done by giving the vifibnet address of the server. Anyways, if you give the 'internet' address of the server,
24         it CANNOT be reached via vifib, as there isn't yet a border vpn through which the internet traffic would be routed
25
26     U : The peer DB size should depend on the number of connection and the refresh time
27     G : ?! I don't agree, the db size should be proportional ( with a factor like 0.01 or less ) to the total number of peers in the entire network, with maybe a max size.
28
29     U : Remove the --no-boot option since we know when no node is avalaible
30     G : the no-boot option is only useful when the server knows no peer,
31         irl it should never happen, no-boot is a debug option
32     U : Ok, but the server knows when no peers is avalaible, doesn't he ?
33     G : Well when no peer is available the SQL request ( + next() method ) raise a StopIteration exception
34
35     G : don't reconnect to server each time we repopulate in peers_db ?
36     U : From what I've read on the internet, when you create a server object, you don't connect to the server,
37         You only connect to the server once you send a request for a methode and then you can automatically use the same connection for 15sec
38     G : ok, it justs need testing ( for when some requests for the server will require to be plugged in the network )
39
40     U : Use more than one boostrap node
41     G : we'll use the server as a bootstrap node