[OLSR-users] RE: Dot topology plugin

[John Gorkos]

>We are here considering programming a simple plugin that provides access to
>OLSRD internal state. As mentioned in my previous message, it should allow
>multiple clients.
>
>This would be more flexible than providing a DOT description of the network.
>If one wants a DOT description, a small program that connects, grabs the
>OLSRD internal state, and generates the DOT would suffice. More modular.
>
>Here are the alternatives. I would like to hear you opinion before starting
>to code:
>
>Threads:
>
>1- Non-threaded plugin. Has the potential "send() block" problem I
>described.
>
>2- Threaded plugin. A bit more complex.
>
>Notification/polling:
>
>1- Notification: a client connects. Immediatelly, it gets the current OLSRD
>internal state. Then, as long as the connection is open, it gets the new
>state every time it changes.
>
>2- Polling: a client connects, and sends a simple command to which the
>plugin responds sending the OLSRD internal state.
>
>Polling has the advantage that when implemented as a non-threaded plugin, it
>is very unlikely to display the "send() block" problem, since the plugin
>will send only upon request. If the clien vanishes from the network the TCP
>buffers will not become full, unless the complete internal state is bigger
>that the TCP buffers.
>  
>
Using olsr from a commercial standpoint brings me to the following place:
1.  I need a single point of information that will let me see the entire 
network topology.
2.  I need to be able to have multiple clients connected receiving 
topology information.
3.  The amount of information I need is minimal (i.e. the DOT file is 
great, but contains more information than I need).  I really only need 
IPa-IPb:status.
  The idea for me is to write a java applet that connects to a mapserver 
and downloads an image of a geographic area, and then opens a TCP 
connection to a single node in the mesh network and begins displaying 
node status in real-time.  This brings up the necesity of some type of 
geo-coded information, and where to store it.  Right now, I have a flat 
file that has IP-address, longitude, latitude and I do a lookup every 
time I re-draw the map.
  In a future iteration, it would be really slick to have a geo-coding 
message in the OLSR stream itself.  This plugin would be able to either 
read static data from a file (or from the configuration file), or 
connect to a gpsd daemon and read real-time positional data.
  The ability to visualize the network is increasingly important as the 
number of nodes increases.  Having a plugin that can support multiple 
clients and provide an immediate network picture, followed by periodic 
updates, is essential to commercialization of olsr.

John Gorkos