TODO

   1 To be done :
   2     use the server as a bootstrap node
   3
   4     Use an algorithm to choose which connections to keep and/or establish
   5     instead of pure randomness
   6
   7     Find a name for the project : the projet is ( or should be ) independant
   8     from vifib, openvpn, babel, and so should the name; btw we aim to build a
   9     distributed, scalable, resilient VPN.... ( if it helps with the name )
  10
  11     Replace comments at the beginning of functions with docstrings & give all
  12     fn docstrings
  13
  14     Use the server events ( client connection/deconnection ) to do something
  15     useful
  16
  17     In peers DB, flag the dead peers so we only choose them if necessary and we can remove them if we have enought peers
  18
  19     Use a timeout for the server peersDB so we can rflag unreachable peers and
  20     remove the peers whose certificate is no longer valid
  21
  22     Specify a lease duration in ForwardViaUPnP
  23
  24     Handle LAN internally in order not to have catastrophic results ....
  25
  26 To be discussed:
  27     G, J : To get traffic stats ( bytes in/out ), you can use
  28           /sys/class/net/interface/statistics/rx_bytes, etc...
  29         or /proc/net/dev/snmp6/interface ( all in one file ). This can be enough
  30         if used as follows: get traffic diff from last time we checked in order
  31         to choose which connection is significantly unused compared to others,
  32         and close it. Of course, too recent connections (i.e. those for which we
  33         have no previous stat) would be always kept.
  34         This should be combined with routing table (i.e. how many nodes are
  35         served by each tunnel), which is possibly redundant.
  36         ip6tables should be avoided if possible.
  37     U : Great !!!
  38
  39     U : Babel seems to be very long to establish the routes : maybe we should
  40         tell him thant we are not on a wired network but on a mobile network ?
  41     G : babel establish routes quickly enough i'd say. There are two new
  42         options : hello and wireless, for hello_interval and treating all
  43         interfaces as wireless. However, treating an interface as wireless
  44         doesn't lessen the hello_interval, it only changes how babel estimates
  45         quality link, and cost.
  46     U : from babel web page : "When the Babel daemon detects a wired network,
  47         it will use a larger interval between hellos".
  48         Moreover, it seems that the wireless option only means
  49         "hostile environment" which seems best for a resilient network.
  50         30 sec of hello interval seams also too much. The default value for
  51         babel is 4 sec (from babel man page).
  52         According to raphael's stats on the nexedi's server downtime,
  53         45% of the problems dont last more than 2 minutes, 55% no more than
  54         3 minutes If it takes 2 min to detect a dead connection, then we wont be
  55         solving many problems with our overlay network
  56
  57     U : The peer DB size should depend on the number of connection and the
  58         refresh time
  59     G : ?! I don't agree, the db size should be proportional ( with a factor
  60         like 0.01 or less ) to the total number of peers in the entire network,
  61         with maybe a max size.
  62     U : what we need to do  is to keep the randomness. For this, we need a big
  63         enought DB to ensure we can still choose a peer as if it was choosen
  64         directly from the server. The requiered db size can be calculated from
  65         the number of connections and the refresh time.
  66
  67     G : don't reconnect to server each time we repopulate in peers_db ?
  68     U : From what I've read on the internet, when you create a server object,
  69         you don't connect to the server, You only connect to the server once you
  70         send a request for a methode and then you can automatically use the same
  71         connection for 15sec
  72     G : ok, it justs need testing ( for when some requests for the server will
  73         require to be plugged in the network )