[OLSR-users] Re: Dot topology plugin

[Andreas Tønnesen]

Hi,

I do not have too much time to work on plugins these days - and I have 
never really used the dot_draw plugin. So please submit patches - or 
even better, take over maintainance of the plugin ;)
That beein said - if anybody is interested in taking over development of 
_any_ of the plugins then please let me know.

- Andreas

Ignacio García Pérez wrote:
> Hi,
> 
> Today I needed to represent my network topology and voila!, there is the dot
> plugin!. However, after closer examination, I've found several shortcomings.
> I may be wrong, so I'll share my thoughts here before starting to code:
> 
> 1- Admits only *one* connection.
> 
> 2- The DOT description is issued only when network topology changes.
> 
> The second point makes this plugin pretty useless for anything but
> debugging. I guess the right way of operation would be to send current
> topology when a client connects to the socket, and then send new topology
> only on changes. In addition, some terminator should be sent to indicate the
> end of the DOT description.
> 
> Implementing this should be pretty easy. Just write the current topology
> after the accept(). Accepting several connections should be not much harder:
> just write to all client sockets the new DOT when topology changes.
> 
> I see also another more subtle shortcoming: what does happen to a socket
> whose connection is lost when you repeatedly write() or send() ?. Suppose
> the client is disconnected from the network. Though the TCP connection will
> eventually time out, I guess there is a chance that, if you write a lot of
> data, the write() or send() call will block, whenever the underlying buffers
> are full. Since writes are done from the plugin event callback, if write()
> or send() blocks then OLSRD will block.
> 
> Yeah, I know the plugin currently only accepts connections from the loopback
> interface and in this situation a blocking is not very likely to happen, but
> I also want to modify the plugin to allow remote connections.
> 
> I've addressed this problem before: make the plugin multithreaded, one
> thread per client. The event callback creates the DOT description in a
> memory buffer protected by a mutex and signals one semaphore per thread.
> Threads wake up, make a local copy of the DOT (using the mutex to avoid race
> conditions) and then rushlessly write from the local copy to the socket.
> Note that this can use quite a lot of memory if topology is big and there
> are many clients connected.
> 
> Any suggestions of which path to take ?
> 
> Thanks.
> 
> 
> ---
> 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: 15/10/2004
> 

-- 
Andreas Tønnesen
http://www.olsr.org