[Berlin-wireless] Service Control Module for Freimap - GSoC proposal

[Sagie]

Hello. Attached is my GSoC proposal. I would be very happy to be able to
respond to any feedback in order to update the proposal in time. Thanks!

Sagie

--- Synopsis ---

This project aims to enhance the Freimap mesh network analysis tool by
adding functionality to actively interact with the network being
monitored. Another goal is to port the UI to Java-Gnome in order to
separate presentation & model. This will provide a position from which a
major enhancement of the existing UI will be made.

Network interaction will enable remote command execution on mesh nodes &
will be available through context driven menus. Design will focus on
modularity to enable future interaction forms to be built on-top of the
remote execution module. 

--- Design ---

A major goal of this project is to lay good foundations on which further
functionality can later on be added. This requires a good understanding
of what this tool is planned to do - will a 3D rendering engine
eventually be introduced ? will network simulations require the ability
to inject fake faults into the mesh network ? will nodes always be
mapped by geo coordinates ? more immediate questions needing resolution
is SSH's capability to answer all remote interaction needs in terms of
speed & functionality, determining if batch application of network
settings on multiple selected nodes is required & setting catering for
live data capturing. 

The following steps may be considered: as a starting point a more more
clear 'multi-tier' design should be visible in the packaging system.
This would also ease integration of any database output implementation
chosen. The newly introduced SSH remote execution module will be
designed in a way in which new remote functionality can be easily added
( ie. full command wrapping & execution through a dedicated thread. an
example of such a command wrapper class is available in the Zenmap
project ).

Multiple element selection (UI) should be expressed through design even
if initially not used - this is done with the intention of basing
relevant context menu items on it. Another design objective is to be
able to present real time charting in a way which would blend naturally
into the UI design while avoiding a major performance penalty.

More obvious steps involve the an 'ConnectableFreiNode' class extending
'FreiNode'  with a 'connect' method to initialize a SSH communication
with the node. so is the extension of the by 'AnntenaNode' in
preparation for displaying antenna orientation & TX power.

Issues I have obtain a definitive solution to is the finding the most
appropriate location to perform filtering before presenting it on the UI
- this may be needed on many occasions such as to when filtering nodes
by service/connection-count/signal-strength or when filtering edges
based on traffic throughput, etc.

Some of these questions should gain much clarity from feedback from the
Freifunk community.

--- Sought Features & Implementation ---

[-] SSH communication channels with remote nodes
SSH interaction may use pssh, openssh or similar. Once setting SSH
channels is available in the core, a select set of commands will be
implemented including traceroute, ping, node restart, etc. Later the
option to open an SSH console to a selected Freifunk node will be added
to the UI (this will be introduced as a dockable widget pane,
connectable nodes will have a special icon). 

[-] visualization layers
many useful visualization techniques are available for mesh network
analysis - naming a few:
- automatic node clustering based on zoom
- varied edge opacity based on number of retransmissions / TX
collisions.
- 'Heat' colorizing of edges corresponding to signal-strength/avg.
throughput/load vs. signal strength and so on... 
these could make mesh bottle necks stand out & point out unreliable
network segments.

The 'VisorLayer' is a good start but would probable have to be expanded
to support all the different possible filtering modes. Once a
satisfiable layer representation is obtained the next step would be to
implement a tree style selection pane with selection boxes to easily
un/hide which visorlayers are displayed ( this would use the powerful
GTK treemap model ). Ability to selectively pick data layers would also
keep large scale scenarios clear.

[-] UI
context driven menus while a single node is selected will include :
  - SSH command invocation: traceroute, ping, etc.  
  - open SSH console
  - display SNMP related data ( if available )
  - list available services
  - monitor real-time statistics (dockable pane)  

context driven menus while a single edge is selected will include :
  - display statistics
  - simulate fault (long term ?)
  - sniff connection (long term ?)

[ please see a UI mockup adopted from my last year's OLPC proposal:
  http://www.cs.bgu.ac.il/~sagiea/projects/freimap/freimap%20tool%
20mockup.png ]

Animation control should probable reside in a dedicated animation
toolbar.

Overall the UI won't present ground braking technology, but a special
effort will be made to make the UI intuitive & clear. Integrating core
functionality once tested should be relatively straightforward. 

--- Development Methodology ---

Emphasis on Test-Driven development will be taken with the intention of
preceding every feature implementation with the necessary tests to
verify it's correctness. All functionality will be developed from the
bottom up, ending at UI integration.  

The main advantage of switching to GTK+ & Java-Gnome library would be
the ability to use xml GUI layouts thus separating 'presentation' from
the data model. Linking the current swing handlers to their GTK
corresponding elements shouldn't raise any special problems & take very
little time. The combination of Glade, Java-Gnome & the Java programming
language could allow very rapid development speeds & when used in
conjunction with JUnit text classes produce high quality code. 

Further investigation should be made into the authentication model that
is used for SSH connection setup - it could be very useful for willing
participants to enable a some form of remote connection while
researching / testing protocol performance.

--- Deliverables ---

   1.  port existing GUI classes to Java-Gnome & GTK
   2.  extract UI design into .glade xml - this will help clean UI
layout code such as VisorFrame.initDialogs() 
   3.  three-tier layerization of current code base via UI, MODEL & Data
code packaging
   4.  remote node command channels via SSH
   5.  context driven menus for single selected nodes / links
   6.  context driven menus for multiple selected elements 
   7.  layer selection pane
   8.  overall documentation of bulk of current code base & all
additional code
   9.  implement the tile cache ( optional )
  10.  internationalization of UI ( optional )
  11.  consider a 3d graphics engine instead of tiling ( optional )