View of /netsukuku/src/TOCODE

    1 --
    2 This is a list of TODOs, which can be implemented in parallel with the
    3 mainstream development of Netsukuku, i.e. you can pick one of the following at
    4 your liking and implement it without worrying too much of the compatibility
    5 with Ntkd.
    6 
    7 However, if you're going to develop one of these TODOs, tell us.
    8 (Use the mailing list).
    9 
   10 Note: These TODOs are not ordered.
   11 --
   12 
   13 - Python bindings
   14 
   15   Interface the exported API to python.
   16 
   17   The idea is to have a "core" written in C, and the rest in python, using a
   18   minimal py interpreter. This would save a lot of development.
   19   The "core" can be defined as everything which exports its own API and it's
   20   used by at least one other source. For example, these would be surely in the
   21   core: event.h, map.c, qspn.c, tracer.c
   22   In other words, whatever doesn't require a strict memory and cpu
   23   control, can be implemented in python.
   24 
   25   Mini TODO: find a good mini-python-interpreter. The desiderable size should
   26   be ~200Kb
   27 
   28 - Interactive shell/console.
   29 
   30   If the "Python bindings" TODO is developed, then this TODO becomes easy:
   31   just use readline() or a simple shell written in python and let the user
   32   use the python bindings.
   33 
   34  Example of commands that should be implemented:
   35     "stats" gives statistics,
   36     "rnodes" show the list of rnodes,
   37     "int_map" dumps the internal map in a ASCIIful way,
   38     "ext_map", "bnode_map", "andna_cache", ...,
   39     "flush rhcache"
   40 
   41 - RSA implementation of signature aggregation, see:
   42   A Survey of Two Signature Aggregation Techniques:
   43     http://crypto.stanford.edu/~dabo/abstracts/aggsurvey.html
   44 
   45   Aggregate and Verifiably Encrypted Signatures from Bilinear Maps:
   46     http://crypto.stanford.edu/~dabo/abstracts/aggreg.html
   47 
   48 
   49  - Ntk_net_split (NTK_RFC 0012).
   50    http://lab.dyne.org/Ntk_net_split
   51 
   52    This RFC, once implemented, would be very useful, because it will deprecate
   53    the "restricted mode", allowing Netsukuku to use the full range of IPs.
   54 
   55    There's some magic to do with iptables, but it shouldn't be too
   56    complicated.
   57 
   58    Moreover, this TODO can be implemented totally in parallel. Even better, it
   59    can be developed as a stand alone application: it can be useful on its own.
   60 
   61  - Ntk_bandwidth_measurement (NTK_RFC 0002)
   62    http://lab.dyne.org/Ntk_bandwidth_measurement
   63 
   64    Use libpcap to measure the amount of utilised and free bandwidth of each
   65    network card.
   66 
   67    In general terms, Ntkd is interested in these two calls:
   68 
   69   (int) current_available_bw(NIC *mynic);
   70   (int) current_used_bw(NIC *mynic);
   71 
   72    See the RFC for more details.
   73 
   74  - Ntk_carciofo (NTK_RFC 0011)
   75    http://lab.dyne.org/Ntk_carciofo
   76 
   77    Carciofo can be implemented in parallel using the API maps exported by
   78    Ntkd (like andna does). However this is a though one and requires a lot of
   79    work.
   80 
   81  - Extend the Q2 simulator. Let it be modular and expandible, and let it
   82    simulate even multi-gnodes and levels.
   83    See http://cvs.hinezumi.org/viewcvs/netsukuku/proto/doc/qspn/q2sim.py
   84 
   85  - Documentation:
   86 
   87   - Write a document which explain why and how is it possible to easily
   88     build efficient distributed structure over Netsukuku (p2p file
   89     sharing, and so on...)
   90     The reason is simple:
   91       - You have access to the maps of a p2p network
   92     - You can append data of your own in the QSPN packets
   93 
   94     In this case, ANDNA is the model. In fact, it is a simple
   95     distributed/p2p structure which exploits the Netsukuku maps.
   96 
   97  - Use qemu to make Netsukuku run on windows?
   98 
   99    You need simply to verify if:
  100 
  101     1) the Linux Advanced Routing works on qemu:
  102     ip route
  103     ip rule
  104     and this sort of things
  105 
  106         2) the emulated host can be used as a default gw by Windows
  107 
  108   3) A generic wifi/network card, installed on Windows, can be used
  109      inside qemu
  110 
  111    If this works, then Netsukuku can be used on Windows, and since Ntkd
  112    requires little cpu and memory power, we don't need to worry anymore about
  113    porting issues.
  114 
  115 - A firewall script to turn a ntk node into a routing only node.
  116   This is more simple to code than to describe:
  117 
  118 
  119                 other ntk nodes
  120                  |
  121            |
  122            |
  123        _________
  124       |    N    |
  125     Internet ---------- | WRT ntk | - - w i f i - - - Ntk node A
  126       |_________|             \
  127            |                   \
  128            |                    \ Ntk node B
  129          L A N
  130 
  131   If N is set to a routing only node, then the nodes A and B will always be
  132   able to reach the Internet and the "other ntk nodes" through it, but they
  133   will not be able to reach the LAN connected to the node N.
  134   Optionally the node N can leave some "backdoor" ports opened, f.e. it might
  135   want to leave a ssh login which accepts keys authentication only.
  136 
  137   The port used by Netsukuku will be leaved open too, in this way the nodes
  138   can still communicate between them.
  139 
  140 - Write packagizing scripts for .deb, .rpm, ....
  141   http://lists.dyne.org/netsukuku/msg00610.php
  142 
  143