TODO

   1 G : We should focus on clearing the TODO List, then go to testing phase,
   2     since the end is nearing... ( I finish on august, 3 )
   3
   4 To be done :
   5     Catch a more precise exception thant Exception at line 108 in vifibnet.py
   6     ( UPnP forwarding )
   7
   8     Upgrade the logging function in order to be able to log message like
   9     "Refreshing peers DB ... done", or add log messages to specify that an
  10     action advertised by a previous log message has been completed
  11
  12     use the server as a bootstrap node -> switch peer discovery to be done
  13     by vifibnet directly ?
  14
  15     Use an algorithm to choose which connections to keep and/or establish
  16     instead of pure randomness
  17
  18     Find a name for the project : the projet is ( or should be ) independant
  19     from vifib, openvpn, babel, and so should the name; btw we aim to build a
  20     distributed, scalable, resilient VPN.... ( if it helps with the name )
  21
  22     Replace comments at the beginning of functions with docstrings & give all
  23     fn docstrings
  24
  25     In peers DB, flag the dead peers so we only choose them if necessary and we
  26     can remove them if we have enought peers
  27
  28     Use a timeout for the server peersDB so we can flag unreachable peers and
  29     remove the peers whose certificate is no longer valid
  30
  31     Specify a lease duration in ForwardViaUPnP
  32
  33     Handle LAN internally in order not to have catastrophic results ....
  34     ( avahi could be used )
  35
  36 To be discussed:
  37     G, J : To get traffic stats ( bytes in/out ), you can use
  38           /sys/class/net/interface/statistics/rx_bytes, etc...
  39         or /proc/net/dev/snmp6/interface ( all in one file ). This can be enough
  40         if used as follows: get traffic diff from last time we checked in order
  41         to choose which connection is significantly unused compared to others,
  42         and close it. Of course, too recent connections (i.e. those for which we
  43         have no previous stat) would be always kept.
  44         This should be combined with routing table (i.e. how many nodes are
  45         served by each tunnel), which is possibly redundant.
  46         ip6tables should be avoided if possible.
  47     U : Great !!!
  48
  49     U : Babel seems to be very long to establish the routes : maybe we should
  50         tell him thant we are not on a wired network but on a mobile network ?
  51     G : babel establish routes quickly enough i'd say. There are two new
  52         options : hello and wireless, for hello_interval and treating all
  53         interfaces as wireless. However, treating an interface as wireless
  54         doesn't lessen the hello_interval, it only changes how babel estimates
  55         quality link, and cost.
  56     U : from babel web page : "When the Babel daemon detects a wired network,
  57         it will use a larger interval between hellos".
  58         Moreover, it seems that the wireless option only means
  59         "hostile environment" which seems best for a resilient network.
  60         30 sec of hello interval seams also too much. The default value for
  61         babel is 4 sec (from babel man page).
  62         According to raphael's stats on the nexedi's server downtime,
  63         45% of the problems dont last more than 2 minutes, 55% no more than
  64         3 minutes If it takes 2 min to detect a dead connection, then we wont be
  65         solving many problems with our overlay network
  66     G : ok, so babel hello-interval should be set to a lower value,
  67         we should do some tests to pinpoint the best compromise between
  68         speed and bandwith usage.
  69         Btw, is there a doc ( pdf, image, file ) resuming Raphael's stats
  70         on nexedi's server downtime ? it could be useful for the internship
  71         rapport
  72
  73     U : The peer DB size should depend on the number of connection and the
  74         refresh time
  75     G : ?! I don't agree, the db size should be proportional ( with a factor
  76         like 0.01 or less ) to the total number of peers in the entire network,
  77         with maybe a max size.
  78     U : what we need to do  is to keep the randomness. For this, we need a big
  79         enought DB to ensure we can still choose a peer as if it was choosen
  80         directly from the server. The requiered db size can be calculated from
  81         the number of connections and the refresh time.
  82     G : ok, you can erase this talk
  83
  84     U : Why are --ip and internal-port mutually exclusive ?
  85         Currently upnp only forward via UDP. Should he also forward via TCP ?
  86         Why dont we only use UDP ?
  87         No error should be raised when no upnp is detected : we should allow
  88         machines having public IP to do an automatic configuration using the
  89         discovery by an other peer
  90     G : Actually, i was wrong, --ip and internal-port are no longer exclusive
  91         Julien said udp might not be used by some people because of
  92         restrictions imposed by the ISP ( FAI in french ), so we should
  93         allow both, and act according to the options specifying which servers
  94         to start (upd, tcp-server)
  95
  96     G : I think the number of route going through an interface should be a
  97         Connection attribute, not a dict in tunnelManager