[OLSR-users] Re: Dot topology plugin

[Andreas Tønnesen]

Hi again,

Just some comments on the idea of multithreading the plugin.
I do not believe this can be easily done. As soon as the plugin operates
in a seperate thread from olsrd you have to start considering protecting
critical sections. The access of the topology lists is one such section,
and creating a locking scheme for this would not be possible withouth
altering olsrd to be using some sort of protection on all write accesses
to these lists(which is not going to happen).
I think you should consider making the socket non-blocking and do some
transmission retries (or use select) if send returns EAGAIN which means it
did not manage to transmit all data.

My 0.02$ :-)

- andreas

> 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