TODO 2.8 KB
Newer Older
Guillaume Bury's avatar
Guillaume Bury committed
1 2
For Ulysse : useful is spelled with only ONE l and not two.....

3
Bugs :
Guillaume Bury's avatar
Guillaume Bury committed
4
    When no peer is avalaible, the setup crash without the --no-boot option => see below
5

6
To be done :
Guillaume Bury's avatar
Guillaume Bury committed
7 8 9
   Use an algorithm to choose which connections to keep and/or establish instead or pure randomness
    Find a name for the project : the projet is ( or should be ) independant from vifib, openvpn, babel,
         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
Guillaume Bury's avatar
Guillaume Bury committed
11 12 13
    Use the server events ( client connection/deconnection ) to do something useful
    In peers DB, remove some peers when they are too many of them -> remove the dead peers
    Use a timeout for the peersDB -> ?, removing the dead peers should be enough
14
    Specify a lease duration in ForwardViaUPnP
15

Guillaume Bury's avatar
Guillaume Bury committed
16 17 18 19 20 21 22 23 24 25 26 27 28
To be discussed:
    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 ?
    G : babel establish routes quickly enough i'd say. There are two new options : hello and wireless, for hello_interval and
        treating all interfaces as wireless. However, treating an interface as wireless doesn't lessen the hello_interval, it only
        changes how babel estimates quality link, and cost.

    U : Contact the server using vifibnet and not the underlying network when possible
    G : done by giving the vifibnet address of the server. Anyways, if you give the 'internet' address of the server,
        it CANNOT be reached via vifib, as there isn't yet a border vpn through which the internet traffic would be routed

    U : The peer DB size should depend on the number of connection and the refresh time
    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.

29 30 31 32
    U : Remove the --no-boot option since we know when no node is avalaible
    G : the no-boot option is only useful when the server knows no peer,
        irl it should never happen, no-boot is a debug option
    U : Ok, but the server knows when no peers is avalaible, doesn't he ?
Guillaume Bury's avatar
Guillaume Bury committed
33
    G : Well when no peer is available the SQL request ( + next() method ) raise a StopIteration exception
Guillaume Bury's avatar
Guillaume Bury committed
34

35
    G : don't reconnect to server each time we repopulate in peers_db ?
36 37
    U : From what I've read on the internet, when you create a server object, you don't connect to the server,
        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
Guillaume Bury's avatar
Guillaume Bury committed
38
    G : ok, it justs need testing ( for when some requests for the server will require to be plugged in the network )
39

Guillaume Bury's avatar
Guillaume Bury committed
40 41
    U : Use more than one boostrap node
    G : we'll use the server as a bootstrap node