[OLSR-users] RE: Dot topology plugin

[Ignacio García Pérez]

> 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.

I intend to program such a plugin, so you'll have it. The plugin will accept
several clients and will stream the topology information to all of them.
Actually, it will stream the raw internal structures of olsrd, so some kind
of processing will have to be done in the clients in order to, for example,
generate a DOT file. I think this is more flexible than streaming a DOT
description. On the other hand, this also less portable. I think that the
internal structures of olsrd are not very likely to change, but who knows. A
possible solution would be to stream a structured text file describing the
data... do you think this would be worth? (would take the effort to write
the generation code in the plugin and a parser for the clients).

Also, regarding the implementation, I have several choices and would like to
hear your opinion:

1- plugin-client interaction scheme: streaming or polling?

Though unlikely, streaming may end up saturating the link to the client.
Polling is a bit less inefficient, but gives the client some control on the
update rate. Some network topology changes may go unnoticed though, if the
network bandwidth does not allow fast enough polling. This may be a problem
only when used to analyze the network topology evolution/convergence. Not
very common.

2- threaded-nonthreaded.

nonthreaded has much simpler implementation. Also uses less memory. However,
if writing to one of the connected clients fills the TCP stack buffers, the
write will block and olsrd operation will become blocked too, leading to
some erratic behaviour.

threaded does not have this problem (one thread per client, one thread may
block writing without causing any trouble to olsrd). However, it uses much
more memory (N+1 network topoly storage, N being the number of connected
clients), and this may not be appropriate for certain embedded platforms
(WRT54G?).

I think I'll start with a non-threaded polling plugin. Polling almost
reduces to zero the chances of a socket write block in the scenarios
described above, except for a malicious client sending continuous
requests...

What do you think?

Nacho.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.778 / Virus Database: 525 - Release Date: 10/15/2004