[olsr-dev] new ipc
Tue Mar 7 15:19:07 CET 2006
Am 07.03.2006 um 14:22 schrieb Thomas Lopatic:
>> 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
> 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).
i don't like this so much because for a desktop application like
frontend (in contrast to web frontend) it is more conveniant to just
receive updates, not to poll every x seconds the whole bunch of
> 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.
absolutely. was a bit ambigous in the last post.
excerpt from kismet documentation (doc/DEVEL.client):
Connected to localhost.
Escape character is '^]'.
KISMET: 2.7.1 1038236534 `"Gir"` 20021118101152
!1234 CAPABILITY NETWORK
!1235 ENABLE NETWORK bssid,type,ssid
*NETWORK: 00:40:96:55:A2:72 0 `(spam-protected)`
*NETWORK: 00:A0:F8:41:3C:DD 0 `KrullNet1`
sentences beginning with "*" are sent from the server->client, those
with "!" go vice versa. if you connect to a kismet server you
instantly get the version plus a "*PROTOCOLS:" line. using "!
CAPABILITY protocolname" you can retreive the fieldnames of the
specified protocol. with "!ENABLE protocolname some,field,names" you
tell the server what you exactly want.
the ACK values are all optional.
combined with the idea of an ipc message designating the end of the
instantly available data (call it cache, current state, ...) this
could be a very powerful approach of ipc.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: Signierter Teil der Nachricht
More information about the Olsr-dev