[olsr-dev] new ipc
Tue Mar 7 14:22:02 CET 2006
> so let's think a bit further about a better ipc. for me a better ipc
> would dump all the interesting data after a client connected or (for a
> two-way protocol) after the client expressed it's interests. even data
I would prefer to make this a pure request/response protocol. Let the
client request information and only then supply the information (and
only the requested information). If we supplied information that the
client is not interested in, we would nevertheless force the client to
be able to parse all the information that we supply and from that
extract the information that it is interested in.
So, suppose I wanted to write a Perl script that gets the OLSR routes
from olsrd. I'd like to send something like "get routes\r\n" to olsrd
and then I'd expect olsrd to give me the contents of its internal
routing table. And I would only have to teach my Perl script to parse
the routing information returned in response to my request. If I later
became additionally interested in the nodes neighbours, I'd implement a
second request in my Perl script, e.g. "get neighbours\r\n", and teach
the script how to parse the response.
> from plugins (like nameservice or powerinfo). then the better ipc would
Yes. We should definitely allow plugins to register their own "get
X\r\n" requests and generated responses for them.
> send some sort of EOF and continue with subsequential updates as long
> as the connection stays alive. a better ipc has some sort of modular
I'd prefer to keep it simple and have the client poll olsrd. So, if we
want updated information, we'd simply re-send our request. In this way
it is up to the client to decide when it needs new information and which
information it is that it needs.
But I agree that we should keep it modular. Maybe a TCL-like command format:
<plugin> <command> <argument> [<argument> [<argument> [...]]]
<plugin> would identify the plugin to which the command and the
arguments are to be forwarded, e.g.
nameservice resolve 18.104.22.168
olsrd get routes
So, each plugin could register a request parser. The nameservice plugin
would do so under the identifier "nameservice", etc.
> protocol and the dataformat is human readable. this makes it suitable
> for scripting. kismet (1) is somehow related to olsrd regarding the
Yes, suitable for scripting and debugging. Fully agreed.
> architecture (client, server, plugins) and has a very good ipc protocol
> in my opinion.
Interesting. I wasn't aware of this. I'll look into this during the next
couple of days.
> your toughts?
Let's keep going... :-)
More information about the Olsr-dev